Separate main GUI thread from internal operations.

[1nd1g0]

Hello there, Mathias, thanks a lot for your hard work.

Is there any chance for MC to get real multi-threading and separate threads for GUI tabs and device\network operations?
I know thread synchronization is not the easiest thing to do, but once done there will be huge improvement in overall usability.
Hanging the whole process including main window thread while waiting for file system API response is very problematic for active multi-tab users 
Let the tab show some progress animation or text, preferably with cancel button and you will be praised in centuries 

Thanks a lot in advance for your consideration.

[Mathias (Author)]

It already does that for the most part..  All Copy operations are background thread, Folder sizing, file system scanning, and lots of other operations.
Almost everything that can is run in the background threads

[1nd1g0]

I stressed tabs GUI specifically. The whole window freezes when there are tab(s) with network paths that suddenly become unresponsive. It's a long time well-known problem. Possible reason could be that the main window thread and the thread used to update list views via system API requests (or some similar operation) are of the same context. Main window GUI would be worth making separate highest priority thread supervising the others via polling or flags. No direct calls with locks etc.

I hope it would not require huge application architecture changes and refactoring.

Do you need me to track down the culprit via debugger? (symbols would be nice)

[Mathias (Author)]

Then most API calls need to be run in separated thread. and the Core Windows API is not designed for that.
And it would also open up for so many strange issues, So MC would become very unstable for a long time.
But all work that can with resonable effort be run in own threads, are spawned to own threads.

If you write apps using C#/WPF/UWP it is a lot easier to do async call since MS have wrapped most Windows API already as async functions

[1nd1g0]

I see your point. While writting native code, I had to refactor my apps modern-browsers-style, sacrifying system resources in favour of stability. So the whole GUI of my app was separated to an external process. Worker threads were hosted at separate non-gui process(es) with graceful self-desruction mechanism in case GUI process was killed somehow, to avoid orphans. Similar mechanism is used by Windows itself while hosting system services as threads in host processes, separate from GUI. The downside is one thread can freeze several neughbours and more data is duplicated in memory due to context separation. Windows does nothing with it so the whole service host process crashes and restarts. The thread that caused problems should be separated from others in "potentially problematic" host process ready to be killed and restarted from the of failrue or skipping it (depends on settings, user choices, algorythms etc.).