On Mon, May 17, 2010 at 2:37 PM, John Millikin <jmilli...@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 <leim...@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 > > 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
