G'day all. Quoting Peter Simons <[EMAIL PROTECTED]>:
> 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.) In my experience, it depends highly on the application. I currently hack database servers for a living. These have properties which are almost ideal for multithreading. Requests tend to require a lot of work to satisfy, different requests often don't need the same resources (so the server isn't effectively sequential), many operations are I/O bound and so on. Being able to exploit SMP concurrency and being able to get useful work done during iowait result in a net win. Yes, you can use asynchronous I/O, but I usually find this harder to understand than the equivalent multithreaded code. select() and poll() may help, but they are hard to use in conjunction with other kinds of events which don't map to file descriptors, such as SysV semaphores, Unix signals, condition variables, GUI events etc. > Aside from that, it appears to be impossible to combine > poll()-scheduled Haskell code with the "traditionally" > scheduled Haskell code in the same program -- unless you > count busy polling as a viable solution. I don't. I don't count cycles as a rule (unless it really, REALLY matters, which it does on rare occasions), but burning as many as you can while doing precisely nothing is just plain wrong. There's a lot to be said for Win32's unified model of events. Or it would if WaitForMultipleObjects() wasn't limited to an insanely small number of objects. What I think I want is QNX-like pulses. In the Haskell world, we come pretty close with channels and ports. If there was a way to deliver system events via a Channel-like structure without busy polling, that would be really nice. Cheers, Andrew Bromage _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell