poll() POLLHUP behaviour inconsistency

[Jérémie Galarneau]

Hi,

Michael and myself are porting code from Linux to FreeBSD and we have noticed a
peculiar difference in the way poll() events are handled.

In short, we have a process that monitors the lifetime of other processes. It
does so by sharing a pipe between the parent and the child on every fork:
read-end in the parent, write-end in the child. The pipe is not used to
communicate; it's only used to poll() on the death of the child process.

On Linux, poll() is called with a POLLHUP event and nothing else. When
the child process dies, the poll() call returns with 'revents == POLLHUP'.

After some head scratching, we figured that on FreeBSD (12.1 and 12.2) if the
child process died while the parent was not waiting in poll(), we would get
'revents == POLLHUP' on the next invocation of poll(), like we do on Linux.
However, if the parent is in poll() when the child dies, the call to poll()
never unblocks. This resulted in occasional hangs in the application.

I am joining a reproducer [1].


As indicated, changing the 'events' to 'POLLIN | POLLHUP' causes both events to
be delivered in both cases (child dies before/during calling poll()).

The following excerpts of the FreeBSD, Linux, and Open Specification seem
in agreement that passing POLLHUP is unnecessary as it is checked implicitly.

FreeBSD (POLL(2))
  This flag is always checked, even if not present in the events bitmask [...]

Open Group:
  This flag is only valid in the revents bitmask; it shall be ignored in the
  events member.

Linux (poll(2)):
  Hang up (only  returned  in revents; ignored in events).


I am surprised by the behaviour being different depending on the moment the
child process' death occurs.

This is not a big deal for us to work-around, but I would like to know if I
should open a bug and try to fix it or if this is intentional (and perhaps
documented?) behaviour.

Thanks!
Jérémie Galarneau

[1] https://gist.github.com/jgalar/5c3c2673b69fa0df652bda80a88f860c

-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com