Re: Race condition during Dispatcher deconstruction

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 2008-01-08 at 22:56 +0100, Daniel Elstner wrote:
[snip]
> Are you sure? Even for blocking I/O? Because this contradicts the GNU
> libc documentation which I've quoted in a comment in dispatcher.cc:
> 
>   // "Reading or writing pipe data is atomic if the size of data written is not
>   // greater than PIPE_BUF. This means that the data transfer seems to be an
>   // instantaneous unit, in that nothing else in the system can observe a state
>   // in which it is partially complete. Atomic I/O may not begin right away (it
>   // may need to wait for buffer space or for data), but once it does begin it
>   // finishes immediately."
> 
> The SUS documentation excerpt you quoted actually doesn't contradict
> this, since there is no mention of atomic writes or reads.EINTR
        read was interrupted by a signal while it was waiting for input.
        See section 24.5 Primitives Interrupted by Signals. A signal
        will not necessary cause read to return EINTR; it may instead
        result in a successful read which returns fewer bytes than
        requested. 
        
I have to say that it seems to me that the SUS documentation I cited is
unambiguous on the point and in addition it has the following in the
"Input and output: Rationale" section for read():

 "The standard developers considered adding atomicity requirements to a
 pipe or FIFO, but recognized that due to the nature of pipes and FIFOs
 there could be no guarantee of atomicity of reads of {PIPE_BUF} or any
 other size that would be an aid to applications portability."

'man 2 read' on my glibc system also gives me:

 "It is not an error if this number is smaller than the number of bytes
 requested; this may happen for example because fewer bytes are actually
 available right now (maybe because we were close to end-of-file, or
 because we are reading from a pipe, or from a terminal), or because
 read() was interrupted by a signal."

No exception is made for reads of pipes/fifos as in the case of write().

On your citation, I agree that nothing in the system may observe a
partially complete write where the write is of PIPE_BUF or less bytes,
but that does not condition how much of the write has to be read.  In
any event, even if glibc does offer a no-short-read guarantee in excess
of POSIX requirements, that does not help SUN/Solaris users.  I think it
would be better to code a library for the relevant standard, rather than
for glibc.

It is also not clear to me what the GNU documentation means by an atomic
read, and whether it rules out a short read.  As it is concerned with
reading a FIFO, any read must be atomic in its weakest sense, even if it
is short.

Chris