
On Mon, May 17, 2010 at 2:37 PM, John Millikin
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.
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
On Mon, May 17, 2010 at 11:07, David Leimbach
wrote: that you'll eventually have a use for the main thread... otherwise the child thread is buying you nothing. Dave
DBus is an asynchronous protocol; running signal handlers in a common 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