3 ms·

>there isn't really a palpable benefit to be gained from totally re-engineering GUI event handling Sure but you do agree that the event loop/thread lock is a c

>there isn't really a palpable benefit to be gained from totally re-engineering GUI event handling Sure but you do agree that the event loop/thread lock is a cumbersome hack due to the system constraints. If the system was based on clojure/functional concepts (with lw threads) it would be natural to implement it that way. And it would hardly be transparent, you deal with event loops and UI thread lock in explicitly.

NathanRice 15y ago
My experience in user interface coding (though not really my favorite area) has been that event handling is pretty much code and ignore, until you want to do some big nasty thing, at which point you have to implement a callable/runnable interface (in java), queue things up and do some synchronization. This seems to be less of an issue in the browser, though I haven't looked at the implementation details. I do agree that having some kind of multi-threaded greenlet/fiber dispatcher would be more efficient and handle corner cases better. I just don't think your average developer would notice a huge difference.