in reply to Re: using $SIG as an IPC interrupt?
in thread using $SIG as an IPC interrupt?

Thanks. Unfortunately the perl program is not asleep waiting for the signal, it is doing other things. I thought I could fork off a process inside the perl program that would sleep until there is something to read, but it seems like it will be problematic having that process asynchronously tell the parent process to jump into the handler loop. Perhaps not?

Thanks!

Replies are listed 'Best First'.
Re^3: using $SIG as an IPC interrupt?
by samtregar (Abbot) on Aug 21, 2008 at 18:53 UTC
    Yup, that's definitely problematic. I think signals are your only hope here, but you've got some significant problems to solve. For example, recent Perls do not guarantee immediate signal delivery, they only check for new signals between op-codes. Start up a long-running regex and you won't see a signal until it returns. That's better than older Perls though, which had immediate delivery but also offered a side of seg-faults with that meal.

    You may need to re-think your design - trying to have a single process handle IPC and do "other stuff" simultaneously is not a good design. Maybe you can fork off that "other stuff" and send it a signal to stop, or pause, when something more important arrives.

    -sam

[reply]
      I think that is okay - if I can reduce the latency from ~200ms to ~20ms (even 90% of the time), thats a big win. A seg fault would increase the latency exponentially :-) :-) Thanks!
[reply]
Re^3: using $SIG as an IPC interrupt?
by jethro (Monsignor) on Aug 21, 2008 at 18:49 UTC

    In theory threads are better for this since they both have the same data available and you just have to make sure synchronize access to the data.

    In reality perl interpreter threads share only data you declare as shared. But that might be just right for your application. A second thread that sleeps until data arrives and then processes that data independently from the main thread. Or sets a shared variable which could be polled faster than a file descriptor, but that would have to be tested.

    Also perl threads seem to have a bad reputation(??) but I might mix them up with the older threads before 5.6.

[reply]
      Well, I have not had great results with threads in Perl, so that is part of my trepidation. Also, right now the loop calls itself using an ->after() directive, and its not clear to me if the child process could cancel the existing after counter one and immedately call the process. I would hate to go to this effort just to have the parent thread poll on a shared variable rather than a file, I'd like a true 'interrupt' type behaviour. Thanks!
[reply]

In Section Seekers of Perl Wisdom