On Mon, 18 Apr 2011 17:05:12 +0530 Piyush P Kurur <ppk@cse.iitk.ac.in> wrote:
On Mon, Apr 18, 2011 at 12:59:07PM +0200, Ertugrul Soeylemez wrote:
Svein Ove Aas <svein.ove@aas.no> wrote: To add a bit more. The most common use of select/epoll is to simulate the concurrency because the natural way of doing it fork/pthread_create etc are too expensive. I dont know of any other reason why select/epoll exits.
You know, I've *never* written a select/kqueue loop because fork/pthread/etc. were to expensive (and I can remember when fork was cheap). I always use it because the languages I'm working in have sucky tools for dealing with concurrency, so it's easier just to avoid the problems by not writing concurrent code.
If fork was trivial in terms of overhead, then one would rather write a webserver as
forever do accept the next connection handle the request in the new child thread/process
Only if you also made the TCP/IP connection overhead trivial so you could stop with HTTP/1.0 and not deal with HTTP/1.1. Failing that, the most natural way to do this is: forever do accept the next connection handle requests from connection in new child wait for next events if one is a client request, start the response if one is a finished response, return it to the client if one is something else, something broke, deal with it. I.e, an event-driven loop for each incoming connection running in it's own process.
This is because it is a natural ``lift'' of the client handling code to many clients (While coding the handling code one need not worry about the other threads).
Still true - at least if you don't try and create a thread for each request on a connection. If you do that, then the threads on a connection have to worry about each other. Which is why the event loop for the second stage is more natural than creating more threads.
GHC's runtime with forkIO makes this natural server code efficient. It might use epoll/kqueue/black magic/sale of souls to the devil I don't care.
But doesn't remove the need for some kind of event handling tool in each thread. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org