Messages in this thread | | | Date | Thu, 13 Jul 2000 12:14:29 -0400 | From | Uncle George <> | Subject | Re: SIGIO signals not generated in Redhat 6.2? |
| |
It seems that someone has attempted to do O_NONBLOCK in fs/pipe.c. ie: if (filp->f_flags & O_NONBLOCK) { if (PIPE_LOCK(*inode)) return -EAGAIN;
the code for O_ASYNC just hasn't appeared yet.
Since u never know when the reader will bother ( even if at all ) to read the pipe, it would be expedient to the writer to not wait & not check at various intervals. This is what SIGIO is ment to prevent.
Richard B. Johnson wrote:
> On Wed, 12 Jul 2000, Uncle George wrote: > > > there does not seem ( from my cursory look ) to be any code in fs/pipe.c > > that handles the dispatching of SIGIO's. Looking for SIGIO's on other > > device drivers leads me to believe that the SIGIO signal is not implimented > > for all drivers. Could also be that SIGIO is centrally dispatched - and > > havent found it yet. > > Any comments from the linux-kernel folks ? > > /gat > > anyway i'd still like to see that small sample that u say fails this. > > This came up about a year ago. From what I remember, it was determined > that pipes are not supposed to generate signals when data are available > because you can't even write to a pipe unless you have a reader already > reading. Basically, the pipe will block on a write until somebody > reads it and a reader will block until somebody writes. Attempts to > set the pipes to non-blocking violates some spec (perhaps POSIX) so > the result is undefined. > > This was what was explained to me when I reported what I thought was a > bug. You need to use UNIX Sockets for interprocess communication > instead of pipes if you want signals for synchronization. Sockets > produce the behavior you expect. >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |