On Mon, 18 Apr 2011 17:05:12 +0530
Piyush P Kurur <p...@cse.iitk.ac.in> wrote:
> On Mon, Apr 18, 2011 at 12:59:07PM +0200, Ertugrul Soeylemez wrote:
> > Svein Ove Aas <svein....@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 <m...@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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
