On Tue, May 18, 2010 at 08:06, David Leimbach wrote:
> 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 int
On Tue, May 18, 2010 at 8:06 AM, David Leimbach wrote:
>
>
> On Tue, May 18, 2010 at 7:08 AM, John Millikin wrote:
>
>> On Mon, May 17, 2010 at 19:41, David Leimbach wrote:
>> > Is there not a way to multiplex the signal handlers into one thread, and
>> > then dispatch new threads to do the work
On Tue, May 18, 2010 at 7:08 AM, John Millikin wrote:
> On Mon, May 17, 2010 at 19:41, David Leimbach 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 wou
On Mon, May 17, 2010 at 19:41, David Leimbach 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,
On Mon, May 17, 2010 at 2:37 PM, John Millikin 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 M
On Mon, May 17, 2010 at 7:12 PM, Don Stewart wrote:
> dpx.infinity:
>> Hi,
>> I'm writing a program which listens to some D-Bus signals using
>> DBus.Client.onSignal function from dbus-client package. This function
>> runs IO action in separate haskell thread when signal is received. My
>> program
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 wrote:
> You could ask y
Use our threads package [1].
import Control.Concurrent.Thread ( forkIO, wait_ )
myDBusThingie :: IO ()
myDBusThingie = error "TODO"
main :: IO ()
main = do tid <- forkIO myDBusThingie
wait_ tid
But like David said, this is only usefull if you plan on multiple
concurrent waits or doin
On Mon, May 17, 2010 at 10:04 AM, DPX-Infinity wrote:
> Hi,
> I'm writing a program which listens to some D-Bus signals using
> DBus.Client.onSignal function from dbus-client package. This function
> runs IO action in separate haskell thread when signal is received. My
> program does nothing excep
dpx.infinity:
> Hi,
> I'm writing a program which listens to some D-Bus signals using
> DBus.Client.onSignal function from dbus-client package. This function
> runs IO action in separate haskell thread when signal is received. My
> program does nothing except signal handling, so after setting up
>
Hi,
I'm writing a program which listens to some D-Bus signals using
DBus.Client.onSignal function from dbus-client package. This function
runs IO action in separate haskell thread when signal is received. My
program does nothing except signal handling, so after setting up
signals it has to wait ind
11 matches
Mail list logo
