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

[Johan Tibell]

Hi Mike,

On Mon, Apr 18, 2011 at 12:00 PM, Mike Meyer <mwm at mired.org> wrote:

> > It's useful to use non-determinism (i.e. concurrency) to model a server
> > processing multiple requests. Since requests are independent and
> shouldn't
> > impact each other we'd like to model them as such. This implies some
> level
> > of concurrency (whether using threads and processes).
>
> But because the requests are independent, you don't need concurrency
> in this case - parallelism is sufficient. The unix process model works
> quite well. Compared to a threaded model, this is more robust (if a
> process breaks, you can kill and restart it without affecting other
> processes, whereas if a thread breaks, restarting the process and all
> the threads in it is the only safe option) and scalable (you're
> already doing ipc, so moving processes onto more systems is easy, and
> trivial if you design for it). The events handled by a single process
> are simple enough that your callback/event spaghetti can line up in
> nice, straight strands.
>

Threads and processes are both concurrent programming models. You get
parallelism if you map the threads/processes to more than one CPU core.

Processes (and to some extents threads) only scale (well) horizontally;
given more processes you can handle more concurrent requests. However, they
don't scale vertically, given more processes you don't handle a particular
request any faster*. Since GHC's scheduler deals with both CPU bound threads
and I/O bound threads you can use it to process single requests faster. A
typically CPU bound activity is page rendering, which you could break up
like this:

renderPage = firstPart `par` secondPart `pseq` combine firstPart secondPart
  where
    firstPart = render ...
    secondPart = render ...

This would run in GHC's per CPU core thread pool, if there are free CPU
resources to do so.

Regarding robustness I think Simon covered most of that. GHC's RTS gives you
the building blocks you need to write Erland style process
monitoring/restart.

* In theory you could use IPC to implement parallel algorithms using
processes, but it's hard to achieve real world performance gains this way as
the overhead is quite large.

Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell/attachments/20110418/dabc41bf/attachment-0001.htm>