poll() POLLHUP behaviour inconsistency

[Oliver Pinter]

CC: mjg@

On Wednesday, November 4, 2020, Jérémie Galarneau <
jeremie.galarneau at efficios.com> wrote:

> 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
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>