On Mon, Apr 18, 2011 at 12:59:07PM +0200, Ertugrul Soeylemez wrote:
> Svein Ove Aas <[email protected]> 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 don't 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/whatever
to achieve this, 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
[email protected]
http://www.haskell.org/mailman/listinfo/haskell
