Should all event-driven frameworks be single-threaded?

Question

http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html argues that multithreaded GUI frameworks are a failed dream. What about non-GUI frameworks? Does this r

Answer 1

In general, yes, since event driven frameworks are similar to the Reactor pattern, which stipulates a main loop which waits for events (the "event loop", and then invokes the registered callbacks for the various elements.

This is how event-driven frameworks have been traditionally defined. Here's a nice description about how Erlang processes are tied to the VM's event loop:

Erlang processes are tightly integrated with the Erlang VM’s event-driven network IO core. Processes can “own” sockets and send and receive messages to/from sockets. This provides the elegance of concurrency-oriented programming plus the scalability of event-driven IO (the Erlang VM uses epoll/kqueue under the covers).

http://yarivsblog.com/articles/2008/05/18/erlang-vs-scala/

update: here's some interesting notes that were very influential on me at the time. Note in particular how locks and callbacks interact badly.

http://home.pacbell.net/ouster/threads.pdf