You have a lot of options, since you apparently can control both the C and the perl code.
IIRC, If your perl code simply sleeps forever, any interrupt will stop the sleep early, and allow your code to continue. If sleep doesn't do this, using select will.
Speaking of select, you could have your C program spawn the perl program such that the C program can write to the perl program's stdin (and possibly read from the stdout). The perl code will be able to just wait until something is written, and then continue off merrily until it's ready for the next chunk of data. The only time that this will cause the C code to block is if it's looking for output from perl (if that's a problem, don't - doesn't sound like you need it currently) or if perl is getting really backed up and isn't already waiting for additional data, and its buffer is full (unlikely to be a problem if you're already polling every 200ms). If that's a serious problem, you can read each record from stdin and fork off a child to handle it while you wait for the next chunk, but your system will likely perform better overall if you don't do this (if the perl code is falling behind, you probably don't want dozens of processes all handling huge chunks of data).
If parent/child is a poor choice, perhaps setting up the perl code to listen on a socket would be better. Here you have two choices - you can continue to write to the file and use the socket as the interrupt (which is useful if the C code doesn't have permissions to send the perl code a signal), or you can use that as the pipe for data directly.
To be honest, I don't think blocking is going to be your issue, though that, too can be solved.
In reply to Re: using $SIG as an IPC interrupt?
by Tanktalus
in thread using $SIG as an IPC interrupt?
by bobbob
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |