All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: linux-kernel@vger.kernel.org,
	Christian Brauner <christian@brauner.io>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Oleg Nesterov <oleg@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	Sargun Dhillon <sargun@sargun.me>,
	Aleksa Sarai <cyphar@cyphar.com>,
	linux-kselftest@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v2 0/4] Support non-blocking pidfds
Date: Thu, 3 Sep 2020 16:58:55 -0700	[thread overview]
Message-ID: <20200903235855.GD210207@localhost> (raw)
In-Reply-To: <20200902102130.147672-1-christian.brauner@ubuntu.com>

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 <josh@joshtriplett.org>

- Josh Triplett

  parent reply	other threads:[~2020-09-03 23:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 10:21 [PATCH v2 0/4] Support non-blocking pidfds Christian Brauner
2020-09-02 10:21 ` [PATCH v2 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open() Christian Brauner
2020-09-03 14:31   ` Oleg Nesterov
2020-09-03 14:58   ` Oleg Nesterov
2020-09-03 15:25     ` Christian Brauner
2020-09-03 23:50   ` Josh Triplett
2020-09-02 10:21 ` [PATCH v2 2/4] exit: support non-blocking pidfds Christian Brauner
2020-09-03 14:22   ` Oleg Nesterov
2020-09-03 15:38     ` Christian Brauner
2020-09-03 23:54       ` Josh Triplett
2020-09-03 23:56   ` Josh Triplett
2020-09-04 10:29     ` Christian Brauner
2020-09-02 10:21 ` [PATCH v2 3/4] tests: port pidfd_wait to kselftest harness Christian Brauner
2020-09-02 10:21 ` [PATCH v2 4/4] tests: add waitid() tests for non-blocking pidfds Christian Brauner
2020-09-03 23:58 ` Josh Triplett [this message]
2020-09-04 10:30   ` [PATCH v2 0/4] Support " Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200903235855.GD210207@localhost \
    --to=josh@joshtriplett.org \
    --cc=axboe@kernel.dk \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian@brauner.io \
    --cc=cyphar@cyphar.com \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sargun@sargun.me \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.