Here is some feedback on poll() from our expert int his area...
Cheers,
Don
>> Sorry for the short fuse on this. If we want to fix this in
>> the next POSIX/SUS revision, we need to have updated wording for the
>> draft interpretation before 8am next Tuesday (11/20/2007).
>> I think I talked with you about this issue (i.e., Under exactly
>> what conditions does the poll() POLLHUP flag get set for a pipe or
>> FIFO?) before. The wording that is in the current standard is:
>> "The device has been disconnected. This event and POLLOUT are
>> mutually-exclusive; a stream can never be writable if a hangup
>> has occurred. However, this event and POLLIN, POLLRDNORM,
>> POLLRDBAND, or POLLPRI are not mutually-exclusive. This flag is
>> only valid in the revents bitmask; it shall be ignored in the
>> events member."
>> We altered the first sentence of the wording in a draft interpretation
>> request to instead say:
>> "A device has been disconnected, or a pipe or FIFO has been
>> closed by the last process that had it open for writing."
>> But that implies that poll() would continue returning POLLHUP even if a
>> FIFO is reopened. There are also questions about the lifetime of the
>> condition that triggers a POLLHUP.
>> Assume I have a FIFO that has at some point in the past been
>> open for reading and writing and all file descriptors to it are now
>> closed. If I then open the FIFO for reading only, will a poll() report
>> POLLHUP even though the FIFO had never been open for writing during the
>> lifetime of the current file descriptor? What I really need are the
>> exact set of conditions that will cause poll() to start returning
>> POLLHUP and what conditions will cause poll() to stop returning
>> POLLHUP.
>>
>> Any help you can provide will be greatly appreciated,
>> Don
>
>Hi Don.
>
>This is what happens in Solaris:
>
>Aside:
>One cannot incur POLLHUP from poll() on a FIFO file descriptor
>obtained from a write-only or a read-write open() of a FIFO.
>The file descriptor must be read-only for POLLHUP to be possible.
>
>Initial state:
>A read-only open of a FIFO that has no other read-only opens
>currently in effect yields a file descriptor that does not incur
>POLLHUP from a poll(), regardless of the number (including zero)
>of opens for writing that are in effect, and regardless of the
>open() and close() history of the FIFO. (Hangup state is clear.)
>
>Hangup state set:
>When the last write-only or read-write open() of a FIFO is closed
>for a FIFO that has at least one read-only open() still in effect,
>the hangup state of the FIFO is set and any subsequent poll() on
>the remaining read-only file descriptors will return showing POLLHUP.
>Any subsequent read-only open() of the FIFO inherits the FIFO's
>hangup state and will return showing POLLHUP from a poll().
>
>Hangup state clear:
>The hangup state of a FIFO is cleared when some process opens
>the FIFO for writing or when the last read-only file descriptor
>(in this case, the last open file descriptor) for the FIFO is closed.
>
>So I suggest that you further augment the first sentence in the
>draft interpretation request with another sentence to say:
>
> "A device has been disconnected, or a pipe or FIFO has been
> closed by the last process that had it open for writing.
> Once set, the hangup state of a FIFO persists until some
> process opens the FIFO for writing or until all read-only
> file descriptors for the FIFO are closed."
>
>Hi Don.
>
>One more thing:
>The submitter of the enhancement request wrote:
>
>> I'm requesting clarification on what the behaviour of the poll call
>> (http://www.opengroup.org/onlinepubs/009695399/functions/poll.html)
>> should be when operating on a FIFO for the POLLIN event, where the
>> given FIFO has no writers and no pending data to be read. The
>> referenced document does not make it clear.
>>
>> The documentation for the select
>> (http://www.opengroup.org/onlinepubs/009695399/functions/pselect.html)
>> call clearly states that:
>>
>> A descriptor shall be considered ready for reading when a call to an
>> input function with O_NONBLOCK clear would not block, whether or not
>> the function would transfer data successfully. (The function might
>> return data, an end-of-file indication, or an error other than one
>> indicating that it is blocked, and in each of these cases the
>> descriptor shall be considered ready for reading.)
>>
>> and the documentation for the read
>> (http://www.opengroup.org/onlinepubs/009695399/functions/read.html)
>> call clearly states that:
>>
>> When attempting to read from an empty pipe or FIFO:
>>
>> * If no process has the pipe open for writing, read() shall
>> return 0 to indicate end-of-file.
>>
>> meaning that calling select on a FIFO with no writer and no pending
>> data should not block. The documentation for the call poll is not so
>> clear; please clarify. I believe Programmers at IBM and Sun are also
>> confused; on Solaris 5.9 the poll call blocks in this situation,
>> whereas on AIX 5.3 poll returns immediately with the POLLHUP flag set
>> in revents.
>
>Whereas this is a true statement about Solaris, the only way to get
>into this situation is to open the FIFO with O_RDONLY | O_NONBLOCK.
>
>If the open does not specify O_NONBLOCK, the open() will not return
>until an open() for writing occurs; if the writer then closes the
>FIFO, poll() on the read-only file descriptor returns with POLLHUP.
>
>So there is no way to test the case of calling read() on a FIFO
>opened without the O_NONBLOCK flag unless an open() for write
>has already occurred, and this case is covered for POLLHUP.
>
>Yes, clarification is needed, but I believe Solaris does it the
>correct way.
|