Re: Race condition during Dispatcher deconstruction



Hi,

Am Dienstag, den 08.01.2008, 20:53 +0000 schrieb Chris Vine:

> Incidentally I noticed, when looking at dispatcher.cc, one thing in the
> Glib::DispatchNotifier::pipe_io_handler() method which does not look
> quite right.  It is this, when reading from the pipe:
> 
>   gssize n_read;
> 
>   do
>     n_read = read(fd_receiver_, &data, sizeof(data));
>   while(G_UNLIKELY(n_read < 0) && errno == EINTR);
> 
> This assumes that if a (unix) signal arises, there are only two possible
> outcomes: (i) a complete read, or (ii) no read at all with read()
> returning -1 and errno set to EINTR.  In fact read() does not have the
> same atomic guarantees with a pipe as does write() (and it doesn't need
> to, because a pipe is a FIFO so it is atomic writes rather than atomic
> reads which are important).

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.

Actually, the initial implementation of DispatchNotifier read the data
in a loop as you suggested. I changed it later with the rationale that
the GNU libc documentation says it's OK, and thus I wanted to make a
partial read an error condition.

I'm not aware that anyone has ever hit this condition (you get a fairly
specific message). Of course that isn't proof that the code is
standard-conform. If you could point to a standard document which
contradicts the GNU libc manual, I'd be grateful.

Regards,
--Daniel




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]