Re: Callbacks in io_uring submission queue

[Jens Axboe <axboe@kernel.dk>]

On 6/11/23 9:43?PM, Thomas Marsh wrote:
> Hello. Recently I was busy making a coroutine executor. It was going
> smoothly until the point where I needed to read from stdin. It turns
> out that the default way to do it blocks the thread that executes the
> read. This is not an acceptable situation for the worker thread which
> should execute as many pieces of work as possible. I tried to find how
> to do asynchronous io in Linux, but among the variety of things I came
> across on the web, the io_uring appeared as an appropriate solution at
> first sight. Sadly, soon after going deeper into the io_uring's
> interface, I discovered that the only way to know about the completion
> of submitted work is through polling. This appeared quite counter to
> the premise of asynchronous io, which is to eliminate waiting on
> things.

Not sure how you came to that last completion? You can certainly poll on
the ring fd itself to get notified when there are completions, but you
can also just check the completion ring. That's the common approach.

> Dissatisfied with my findings I tried to see if any other os provided
> a better interface, and I found one conceptually interesting
> approach... in Apple's Metal. In that graphics framework, it is
> possible to ask the system for a command buffer and then put in it a
> user-provided callback, which the system will execute when it
> processes that buffer.
> 
> Is it possible to put a callback in io_uring which the system will
> execute without polling the thing?

io_uring is a kernel side implementation, having callbacks there into
userspace would not make sense. You could of course wrap your completion
reaping in something that processes them via calling a callback, eg
->user_data could be set to a struct that has a data and callback
element and that's how you'd process them.

But it sound to me like you're mixing things up a bit. And there's some
confusion on polling being a requirement as well, which is not the case
at all.

-- 
Jens Axboe