3 ms·

> Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications. Correct me if I'm w

> Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications. Correct me if I'm wrong, but doesn't basically every UI framework from the last 20 years do exactly this?

Matthias247 8y ago
They do, but I think also that possibly every user of such a framework has at least once created a concurrency issue once in their life. All of these the issues below are things I have seen (and created) over and over in these environments: - Trying to access UI framework elements from the wrong thread - not understanding that a callback inside one of the included libraries is not running on the UI thread but from somewhere else - callbacks capturing references to objects which already had been destroyed (but the callback had been queued and can't be cancelled), and accessing those objects later on - deadlocks, due to mutex locking in both callbacks as well as the "normal" code. There are ways to minimize the amount of issues, e.g. always deferring asynchronous callbacks to the next eventloop iteration, making sure that callbacks are queued on the main thread instead of an arbitrary one, deferring object deletion behind all other callbacks, etc. But these are on the harder to learn, teach and enforce side. Therefore I would agree with the author of that article that the mixture of eventloop-based programming and multiple threads is the hardest combination.
tybit 8y ago
C# does this server side too, async isn’t particular fun but threading doesn’t make it any worse when the runtime handles it imo.
zzzcpan 8y ago
> Correct me if I'm wrong, but doesn't basically every UI framework from the last 20 years do exactly this? Yeah, multithreading with event loops was never a big deal. Simple API to run something in a thread pool out of event loop is definitely much easier, than using threads. Apple did Grand Central Dispatch and I believe it's universally recognized to be easier than using threads.

Matthias247 8y ago

They do, but I think also that possibly every user of such a framework has at least once created a concurrency issue once in their life. All of these the issues below are things I have seen (and created) over and over in these environments: - Trying to access UI framework elements from the wrong thread - not understanding that a callback inside one of the included libraries is not running on the UI thread but from somewhere else - callbacks capturing references to objects which already had been destroyed (but the callback had been queued and can't be cancelled), and accessing those objects later on - deadlocks, due to mutex locking in both callbacks as well as the "normal" code. There are ways to minimize the amount of issues, e.g. always deferring asynchronous callbacks to the next eventloop iteration, making sure that callbacks are queued on the main thread instead of an arbitrary one, deferring object deletion behind all other callbacks, etc. But these are on the harder to learn, teach and enforce side. Therefore I would agree with the author of that article that the mixture of eventloop-based programming and multiple threads is the hardest combination.

tybit 8y ago

C# does this server side too, async isn’t particular fun but threading doesn’t make it any worse when the runtime handles it imo.

zzzcpan 8y ago

> Correct me if I'm wrong, but doesn't basically every UI framework from the last 20 years do exactly this? Yeah, multithreading with event loops was never a big deal. Simple API to run something in a thread pool out of event loop is definitely much easier, than using threads. Apple did Grand Central Dispatch and I believe it's universally recognized to be easier than using threads.