Peter Simons <simons@cryp.to> replies:
Paul Graunke writes:
[...] event driven servers (which are supposedly oh so much faster.)
At least in my experience, multiplexing servers _are_ significantly faster than those relying on the OS (or whatever library) to do the scheduling. They also tend to be much more efficient in terms of memory consumption, thus allowing for more simultaneous connections than a fork()ing or pthread_xxx()ing server would. (Not a big surprise, if you think about it.)
For a somewhat-contrary opinion, see the recent SOSP paper "Capriccio: Scalable Threads for Internet Services" by Rob von Behren, Jeremy Condit, Feng Zhou, George Necula, and Eric Brewer: http://www.cs.berkeley.edu/~jcondit/capriccio-sosp-2003.pdf In a nutshell: they wrote a user-level threads package that wrapped the usual library functions and did them all using asynchronous I/O. All the scheduling takes places at user level. The whole system is currently uniprocessor. The threads package they describe is virtually identical to the way threading is implemented in GHC. The overheads? Virtually none compared to writing the program explicitly in an event-driven style (sometimes they're even faster). That said, they were quite a bit more careful about tracking resource demands of various sorts and using them to make clever scheduling decisions. GHC is a bit more naive, but there's nothing ruling out a more clever implementation, and GHC programs written using forkIO would certainly benefit from such optimizations. -Jan-Willem Maessen Resource-aware scheduling freak jmaessen@alum.mit.edu