On Mon, Apr 18, 2011 at 12:59:07PM +0200, Ertugrul Soeylemez wrote:
> Svein Ove Aas <svein....@aas.no> wrote:
>
> > And I've often wanted a select-equivalent in Haskell. It'd be simple,
> > it'd help, so why not?
>
> Because perhaps it's just an illusion that it would help. I don't see
> any advantage in using explicit polling. Use concurrency.
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.
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
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).
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.
And in case you want a shared state just adds an STM and that is it.
Regards
ppk
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
