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.
>
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
