[Haskell] select(2) or poll(2)-like function?

[Mike Meyer]

On Mon, 18 Apr 2011 17:05:12 +0530
Piyush P Kurur <ppk at cse.iitk.ac.in> wrote:

> On Mon, Apr 18, 2011 at 12:59:07PM +0200, Ertugrul Soeylemez wrote:
> > Svein Ove Aas <svein.ove at 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 at 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