Imagine a method like this:

    1. Enqueue A = openat(...)
    2. Enqueue B = read(A, buf, sz)
    3. Enqueue close(A)
    4. Commit, return B to userspace

A and B are placeholders, and A is never known to userspace, it is simply chained within the enqueued commands.

What if openat() or read() fails? More generally, what if there's a chain of syscalls and you _want_ one of them to fail?

With the "specific fd" approach, if openat fails, then read and close will harmlessly fail with EBADF ("Bad file descriptor"). Once you process the failure of openat, you'll just ignore the failure of read and close.

What will happen though, if the fd is already used by some other area of userspace? Like what if some lib you link to also happen to hardcore the use of the same fd. Sounds like unfunny problems to debug.

In the case of uring I suppose it is possible to link the calls to fail at the first failure.

> What will happen though, if the fd is already used by some other area of userspace?

That's what the min_fd patch is for, and potentially other systems for reserving blocks of fds. Much like memory, you'll ask the kernel for a block of it and then do your own allocations out of that.

Ah, it will be possible to allocate multiple blocks of file descriptors? Ok, then things start to make sense.

This seems exactly the io_uring approach with magic fd described in the article.

> You need the handle in advance to queue the second and third.

Think about how pipelined commands work in a command shell if you want to understand how to construct a program that can define a sequence of operations on objects before they're defined.

> You need the handle in advance to queue the second and third

whoops. I probably should have thought of that.