Re: Re: Re: Re: Handling I/O Signals

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 */
    }
  }
[download]

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

Comment on Re: Re: Re: Re: Handling I/O Signals Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Handling I/O Signals by traveler (Parson) on Mar 15, 2002 at 15:38 UTC
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 }` [download] This is used in blocking network servers --traveler	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: Handling I/O Signals
by traveler (Parson) on Mar 15, 2002 at 15:38 UTC

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
}
[download]
```
This is used in blocking network servers

[reply]
[d/l]
[select]