in reply to Re: Handling I/O Signals
in thread Handling I/O Signals

Thanks a lot for all these remarks! Here under I try to address each of the suggestions that have been made:

Otherwise concerning the while loop.. it would be nice to use pause but since I cannot catch the signal in the first place.. I wanted to make the script as straight forward as possible (focus on the SIGIO and nothing else)

Any further ideas/recommendations? Lets say I wan to dial into my computer, and I want a small perl script to handle this: do I have to constantly poll the Serial Port for input from the modem (every 5 or 10 secs.) and "suck" the system ressources (whith a "while loop" ;-)? Or is there another way of doing this in Perl?

Replies are listed 'Best First'.
Re: Re: Re: Handling I/O Signals
by traveler (Parson) on Mar 14, 2002 at 18:47 UTC
    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

      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.. (?)

        1. 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.
        2. True, select "blocks" until input. Your while(1){}; just consumes the CPU until input happens.
        3. 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.
        4. 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