Re: using $SIG as an IPC interrupt?

You could definitely use signals for this, but I probably wouldn't. The easiest way to do this kind of thing is to have your C program write to a pipe (anonymous or named) instead of a real file and have your Perl program use select() to wake up as soon as there's anything to read. I like IO::Select for making select() a little easier to manage. Rumor has it EV performs better, but I haven't tried it yet.

If you're stuck using a real file for the data you need to pass, you could still use the pipe trick by having your C program write its "wake up" notice down the pipe.

-sam

Comment on Re: using $SIG as an IPC interrupt?

Replies are listed 'Best First'.
Re^2: using $SIG as an IPC interrupt? by bobbob (Acolyte) on Aug 21, 2008 at 18:18 UTC
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!	[reply]
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]
Re^4: using $SIG as an IPC interrupt? by bobbob (Acolyte) on Aug 21, 2008 at 19:01 UTC
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]
Re^4: using $SIG as an IPC interrupt? by bobbob (Acolyte) on Aug 21, 2008 at 18:56 UTC
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]