I suggested pause because the while loop may be keeping you from getting the signal in a reasonable amount of time. Someone who knows more perlguts may be able to correct me, but I have had this problem with C under various systems.
select does not require constant polling. It hangs the program waiting for input (or output or a timeout); it thus replaces the while and the need for SIGIO. Do man select on your Linux box. Note that there are two selects in Perl.
Also did you check the HOWTO ref I included?
HTH, --traveler | [reply] [d/l] [select] |
Well.. if the while loop keeps me from receiving the signal, then I dont
understand signals anymore.. ! ;-). Concerning select - as you
say - it hangs the program waiting for input, meaning I cannot do anything
else but just waiting in the meantime.
Otherwise, yes I have checked the HOWTO and allready knew it (I usually
read the Serial Programing HOWTO at linuxdoc.org.
Just for the record, actually I think there is a small flaw in its
Asynchrounous Input example (here under is a small snipet from it):
while (STOP==FALSE) {
printf(".\n");usleep(100000);
/* after receiving SIGIO, wait_flag = FALSE, input is available
and can be read */
if (wait_flag==FALSE) {
res = read(fd,buf,255);
buf[res]=0;
printf(":%s:%d\n", buf, res);
if (res==1) STOP=TRUE; /* stop loop if only a CR was input */
wait_flag = TRUE; /* wait for new input */
}
}
Before this while loop a signal handler was installed, which will
set wait_flag to FALSE if a signal arrives. With this
code, when a signal arrives the buffer will be read, resetted, and
printed out before setting wait_flag back to TRUE again.
But what if some data comes to the port when it is printing out? The
signal handler will set wait_flag to FALSE, and the loop
will set it back to TRUE again afther testing for res..
I think I might just end up waiting (forever) for input that was
allready there.. (?) | [reply] [d/l] [select] |
- Eventually the while(1) will yield to the signal. It depends on the OS and how perl works. It may not be immediate. In Linux/UNIX signals are only delivered to a program when it "wakes up"; that is, when it starts to run after having let another process use the CPU.
- True, select "blocks" until input. Your
while(1){}; just consumes the CPU until input happens.
- In the C code if data comes to the port while printf is printing, the printf may be interrupted for the signal and the flag would be set indicating data were present. That is why the STOP==FALSE test is there.
- Since you have the while(1) loop and it is empty in your example, you could do something like:
while(1){
wait for input via select
process input
}
This is used in blocking network servers
--traveler
| [reply] [d/l] [select] |