Re: [PATCH v2 2/4] exit: support non-blocking pidfds

On Thu, Sep 03, 2020 at 05:38:47PM +0200, Christian Brauner wrote:

On Thu, Sep 03, 2020 at 04:22:42PM +0200, Oleg Nesterov wrote:

quoted

On 09/02, Christian Brauner wrote:

quoted

It also makes the API more consistent and uniform. In essence, waitid() is
treated like a read on a non-blocking pidfd or a recvmsg() on a non-blocking
socket.
With the addition of support for non-blocking pidfds we support the same
functionality that sockets do. For sockets() recvmsg() supports MSG_DONTWAIT
for pidfds waitid() supports WNOHANG.

What I personally do not like is that waitid(WNOHANG) returns zero or EAGAIN
depending on f_flags & O_NONBLOCK... This doesn't match recvmsg(MSG_DONTWAIT)
and doesn't look consistent to me.

It's not my favorite thing either but async event loops are usually
modeled around EAGAIN so I think this has benefits. Josh can speak more
to that.

I wouldn't expect the same application to use both WNOHANG and
O_NONBLOCK, since the latter makes the former unnecessary. I'd have no
objection if WNOHANG continued to have the same "return 0 and you have
to check the structure to figure out what that means" behavior
regardless of the fd flags, for compatibility with an application or
library that expects that behavior with WNOHANG and didn't expect the
return value to change with a non-blocking fd.  waitid could just return
EAGAIN on a non-blocking fd if *not* passed WNOHANG, which would make
pidfd Just Work in non-blocking event loops.