[K42-discussion] Another problem with asynchrony

[Bryan S Rosenburg]

Paul,

Do you know if that's a Posix requirement, a Linux requirement, or simply 
Linux de facto behavior?

Generating the SIGPIPE inside the client-side write/pwrite function could 
be done, but it would clutter up a path that otherwise doesn't know and 
doesn't care whether it's talking to a pipe, a regular file, a socket, or 
something more exotic.  It would be easy to do, but ugly.

- Bryan




"Paul H. Hargrove" <PHHargrove at lbl.gov> 
10/11/2005 04:19 PM

To
Bryan S Rosenburg/Watson/IBM at IBMUS
cc
k42-discussion at ozlabs.org
Subject
Re: [K42-discussion] Another problem with asynchrony






If I am not mistaken, the raise() call had better never return prior to
signal delivery (and handler execution if applicable).
If that is the case, then moving the generation of SIGPIPE from the pipe
server to the write/pwrite function may be a possible fix for this
"behavior".

-Paul

Bryan S Rosenburg wrote:
>
> When you write to a pipe whose other end has been closed, the write is
> supposed to fail with an errno of EPIPE, and in addition you are
> supposed to receive a SIGPIPE.
>
> In Linux, unless you ignore or handle the signal, it will always kill
> you before you get back from the write.  (I make this assertion on
> only a little evidence.)
>
> In K42, the pipe server can generate the signal before returning
> EPIPE, but there's no good way to ensure that the signal is acted on
> before the write returns.  In practice, I've found that the client
> sometimes sees the write return and sometimes it doesn't.
>
> As far as I can tell, Posix says nothing more than:
>
> The /write/() and /pwrite/() functions shall fail if:
> . . . .
> [EPIPE]
> An attempt is made to write to a pipe or FIFO that is not open for
> reading by any process, or that only has one end open. A SIGPIPE
> signal shall also be sent to the thread.
>
> which by itself doesn't seem to imply any degree of synchronicity.
>  But there may be constraints on when a signal "sent" to a thread
> because of the thread's own action must be delivered.
>
> In any case, I think Linux programs will be surprised if they survive
> to see an EPIPE returned from write, whether or not they should be.
>
> I'm not proposing to do anything about this problem right now, but I
> thought I'd put it out for discussion.
>
> - Bryan
>------------------------------------------------------------------------
>
>_______________________________________________
>K42-discussion mailing list
>K42-discussion at ozlabs.org
>https://ozlabs.org/mailman/listinfo/k42-discussion
> 


-- 
Paul H. Hargrove                          PHHargrove at lbl.gov
Future Technologies Group 
HPC Research Department                   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20051011/ba653827/attachment.htm