On Mon, May 17, 2010 at 2:37 PM, John Millikin
<jmillikin@gmail.com> wrote:
Author of dbus-client here. Don Stewart's solution (blocking on an
mvar) is the best way to handle it. Presumably, you've got some way to
make your program shut down (method call? signal handler?) -- just set
the mvar in that.
On Mon, May 17, 2010 at 11:07, David Leimbach <
leimy2k@gmail.com> wrote:
> You could ask yourself why you need a child thread if the main thread
> doesn't do anything else.
> I presume you're at a step in the development of something larger and that
> you'll eventually have a use for the main thread... otherwise the child
> thread is buying you nothing.
> Dave
thread would let one long-running computation block receipt of any
others.
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.
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.
Dave