On Mon, May 17, 2010 at 19:41, David Leimbach <leimy2k@gmail.com> wrote:
> Is there not a way to multiplex the signal handlers into one thread, and
> then dispatch new threads to do the work when events that require such
> concurrency occur?
> That would be the initial way I'd structure such a program.

All signals, method calls, method returns, etc are read from the
socket in a single thread. If some computation needs to be performed,
a thread is spawned. There's no "thread pool", and I doubt such a
construct would provide any benefit.

> In fact, if the results of a computation based on a signal aren't even
> needed immediately, one could rely on the fact that Haskell is a non-strict
> language to partially evaluate an expression and get to it later when it's
> really needed.  Haskell has "built in Futures" of a sort.  That may not be
> appropriate depending on the processing at hand, but it's worth noting that
> it's possible.

I'm not sure what partial evaluation has to do with anything under
discussion. If received messages are processed in the same thread,
then some long-running computation would block that thread (and,
hence, message reception). This occurs regardless of exactly when the
computation is performed, relative to its declaration. Removing the
fork from within the signal/method dispatcher would simply force every
user to write "forkIO $ ..." everywhere.