[K42-discussion] Another problem with asynchrony

[Paul H. Hargrove]

ISO C says

If a signal handler is called, the raise function shall not return until after the signal handler does.

I am not imagining that write will "care" that it is talking to a pipe,
just that the return value is EPIPE:

if (result == EPIPE) raise(SIGPIPE);

-Paul

Bryan S Rosenburg wrote:
>
> 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
>
>


-- 
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