[v2,0/4] Support non-blocking pidfds

Message

Christian Brauner Sept. 2, 2020, 10:21 a.m. UTC

Hi,

Passing a non-blocking pidfd to waitid() currently has no effect, i.e.
is not supported. There are users which would like to use waitid() on
pidfds that are O_NONBLOCK and mix it with pidfds that are blocking and
both pass them to waitid().
The expected behavior is to have waitid() return -EAGAIN for
non-blocking pidfds and to block for blocking pidfds without needing to
perform any additional checks for flags set on the pidfd before passing
it to waitid().
Non-blocking pidfds will return EAGAIN from waitid() when no child
process is ready yet. Returning -EAGAIN for non-blocking pidfds makes it
easier for event loops that handle EAGAIN specially.

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. Both flags are
per-call options. In contrast non-blocking pidfds and non-blocking
sockets are a setting on an open file description affecting all threads
in the calling process as well as other processes that hold file
descriptors referring to the same open file description. Both behaviors,
per call and per open file description, have genuine use-cases.

A concrete use-case that was brought on-list (see [1]) was Josh's async
pidfd library. Ever since the introduction of pidfds and more advanced
async io various programming languages such as Rust have grown support
for async event libraries. These libraries are created to help build
epoll-based event loops around file descriptors. A common pattern is to
automatically make all file descriptors they manage to O_NONBLOCK.

For such libraries the EAGAIN error code is treated specially. When a
function is called that returns EAGAIN the function isn't called again
until the event loop indicates the the file descriptor is ready.
Supporting EAGAIN when waiting on pidfds makes such libraries just work
with little effort.

Thanks!
Christian

[1]: https://lore.kernel.org/lkml/20200811181236.GA18763@localhost/

Christian Brauner (4):
  pidfd: support PIDFD_NONBLOCK in pidfd_open()
  exit: support non-blocking pidfds
  tests: port pidfd_wait to kselftest harness
  tests: add waitid() tests for non-blocking pidfds

 include/uapi/linux/pidfd.h                 |  12 +
 kernel/exit.c                              |  15 +-
 kernel/pid.c                               |  12 +-
 tools/testing/selftests/pidfd/pidfd.h      |   4 +
 tools/testing/selftests/pidfd/pidfd_wait.c | 298 +++++++++------------
 5 files changed, 157 insertions(+), 184 deletions(-)
 create mode 100644 include/uapi/linux/pidfd.h


base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd

Comments

Josh Triplett Sept. 3, 2020, 11:58 p.m. UTC | #1

On Wed, Sep 02, 2020 at 12:21:26PM +0200, Christian Brauner wrote:
> Hi,
> 
> Passing a non-blocking pidfd to waitid() currently has no effect, i.e.
> is not supported. There are users which would like to use waitid() on
> pidfds that are O_NONBLOCK and mix it with pidfds that are blocking and
> both pass them to waitid().
> The expected behavior is to have waitid() return -EAGAIN for
> non-blocking pidfds and to block for blocking pidfds without needing to
> perform any additional checks for flags set on the pidfd before passing
> it to waitid().
> Non-blocking pidfds will return EAGAIN from waitid() when no child
> process is ready yet. Returning -EAGAIN for non-blocking pidfds makes it
> easier for event loops that handle EAGAIN specially.
> 
> 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. Both flags are
> per-call options. In contrast non-blocking pidfds and non-blocking
> sockets are a setting on an open file description affecting all threads
> in the calling process as well as other processes that hold file
> descriptors referring to the same open file description. Both behaviors,
> per call and per open file description, have genuine use-cases.
> 
> A concrete use-case that was brought on-list (see [1]) was Josh's async
> pidfd library. Ever since the introduction of pidfds and more advanced
> async io various programming languages such as Rust have grown support
> for async event libraries. These libraries are created to help build
> epoll-based event loops around file descriptors. A common pattern is to
> automatically make all file descriptors they manage to O_NONBLOCK.
> 
> For such libraries the EAGAIN error code is treated specially. When a
> function is called that returns EAGAIN the function isn't called again
> until the event loop indicates the the file descriptor is ready.
> Supporting EAGAIN when waiting on pidfds makes such libraries just work
> with little effort.

Thanks for the patch series, Christian!

This will make it much easier to use pidfd in non-blocking event loops.

Reviewed-by: Josh Triplett <[e-mail]>

- Josh Triplett

Christian Brauner Sept. 4, 2020, 10:30 a.m. UTC | #2

On Thu, Sep 03, 2020 at 04:58:55PM -0700, Josh Triplett wrote:
> On Wed, Sep 02, 2020 at 12:21:26PM +0200, Christian Brauner wrote:
> > Hi,
> > 
> > Passing a non-blocking pidfd to waitid() currently has no effect, i.e.
> > is not supported. There are users which would like to use waitid() on
> > pidfds that are O_NONBLOCK and mix it with pidfds that are blocking and
> > both pass them to waitid().
> > The expected behavior is to have waitid() return -EAGAIN for
> > non-blocking pidfds and to block for blocking pidfds without needing to
> > perform any additional checks for flags set on the pidfd before passing
> > it to waitid().
> > Non-blocking pidfds will return EAGAIN from waitid() when no child
> > process is ready yet. Returning -EAGAIN for non-blocking pidfds makes it
> > easier for event loops that handle EAGAIN specially.
> > 
> > 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. Both flags are
> > per-call options. In contrast non-blocking pidfds and non-blocking
> > sockets are a setting on an open file description affecting all threads
> > in the calling process as well as other processes that hold file
> > descriptors referring to the same open file description. Both behaviors,
> > per call and per open file description, have genuine use-cases.
> > 
> > A concrete use-case that was brought on-list (see [1]) was Josh's async
> > pidfd library. Ever since the introduction of pidfds and more advanced
> > async io various programming languages such as Rust have grown support
> > for async event libraries. These libraries are created to help build
> > epoll-based event loops around file descriptors. A common pattern is to
> > automatically make all file descriptors they manage to O_NONBLOCK.
> > 
> > For such libraries the EAGAIN error code is treated specially. When a
> > function is called that returns EAGAIN the function isn't called again
> > until the event loop indicates the the file descriptor is ready.
> > Supporting EAGAIN when waiting on pidfds makes such libraries just work
> > with little effort.
> 
> Thanks for the patch series, Christian!
> 
> This will make it much easier to use pidfd in non-blocking event loops.
> 
> Reviewed-by: Josh Triplett <[e-mail]>

Thank you and thanks for your input on a bunch of other stuff as well. :)

Christian