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: > > On 09/02, Christian Brauner wrote: > > > > > > 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.
