[Haskell-cafe] Wait forever in main thread

[David Leimbach]

On Tue, May 18, 2010 at 7:08 AM, John Millikin <jmillikin at gmail.com> wrote:

> On Mon, May 17, 2010 at 19:41, David Leimbach <leimy2k at 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.
>

I think you just said the same thing I just said.  So are we arguing?  I'm
kind of confused.  "If some computation needs to be performed, a thread is
spawned" is very similar to what I just said about multiplexing the signal
handling into one thread and spawning worker threads.

I never mentioned a thread pool, and agree with you that it probably doesn't
make any sense in this discussion.

It might just be that I don't know anything about your DBus library that's
causing this discussion to go this way.  Let me look at it and get back to
you.

>
> > 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.
>


When I think of Haskell, I think of laziness and partial evaluation, so to
me it's always on topic.  Maybe that's because I've been bitten by assuming
strictness where it doesn't exist and had ridiculously bad data leaks in my
code as a result.

What I've been trying to come to terms with is a way to leverage the
laziness rather than constantly striving to turn it off so I get reasonable
runtime footprint of my Haskell programs.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100518/743d127c/attachment.html