cc @the8472 can you check the syscall I added please?

I'm not sure if it is correct, thank you!

what are the numbers on this optimization like?

It would enable try_acquire support on cases where:

• jobserver gets an annoymous pipe instead of named fifo
• procfs is not available
  Without preadv2, try_acquire would return a not-supported error.

On performance, it's mostly for avoiding performance loss with acquire when jobserver receives a named fifo or procfs is available (which jobserver would use to convert pipe to fifo).

Without preadv2,try_acquire would set the fifo to non-blocking, which would cause acquire to enter poll + read if the fifo is empty, which is less efficient than a blocking read.

Maybe we can simplify things by limiting to aarch64, x86_64 linux gnu? Those are probably the most common environments where stuff is built.

Well, from the glibc implementation, it looks like there're only 3 versions for it, so maybe we can still bare with the cost?

And it's mostly a perf optimization, so we can be conservative in which platforms get it.

While it's mostly a perf optimization, there is situation where preadv2 actually enable try_acquire to work properly instead of returning a not-supported error:

• jobserver gets an annoymous pipe instead of named fifo
• procfs is not available
  Without preadv2, try_acquire would return a not-supported error.

what are the numbers on this optimization like?

It would enable try_acquire support on cases where:

* jobserver gets an annoymous pipe instead of named fifo

* procfs is not available
  Without `preadv2`, `try_acquire` would return a not-supported error.

On performance, it's mostly for avoiding performance loss with acquire when jobserver receives a named fifo or procfs is available (which jobserver would use to convert pipe to fifo).

Without preadv2,try_acquire would set the fifo to non-blocking, which would cause acquire to enter poll + read if the fifo is empty, which is less efficient than a blocking read.

Thanks @NobodyXu for the work. Believing that people already know the benefit of this for fixing unsupported situations. What Jubilee asked for are numbers. I think that's a reasonable request for a change aiming at optimization. Could you do some benchmark and show the number, so we can have a baseline in mind? It is also beneficial to prevent from future performance regression if we have the reproducible benchmark steps (if you don't mind sharing).

What Jubilee asked for are numbers. I think that's a reasonable request for a change aiming at optimization. Could you do some benchmark and show the number, so we can have a baseline in mind? It is also beneficial to prevent from future performance regression if we have the reproducible benchmark steps (if you don't mind sharing).

I could add one in benches/, it would first call try_acquire on Linux and then call acquire.
Might have to add criterion as a dev-dep though.

Edit:

Would do that tomorrow.

Note that using blocking reads in acquire is mostly beneficial when there are many concurrent waiters. A single waiter won't see much of a speedup (perhaps a little from the avoided syscalls).

See #30 and torvalds/linux@0ddad21, the latter one has numbers.

Oh, cute, so it is in fact a kernel optimization specifically for this protocol!

Can the code generally minimize amount of #[cfg(...)] in favor of cfg!(...)?
It will get more checking and less surprises on remaining platforms.
#[cfg(...)] is not really needed that often, only when some names are unavailable on some platforms (and even then they can sometimes be defined to dummies, see e.g. how type RawFd is defined).

Can the code generally minimize amount of #[cfg(...)] in favor of cfg!(...)? It will get more checking and less surprises on remaining platforms.

Thanks, I've added the code in preadv2 to use cfg! instead of #[cfg(...)], it's actually more readable now.

Yeah I would add one, I wish libc would support it for musl libc

Or perhaps we could wait till libc support it on musl @the8472 ?

Yeah it's not urgent. try_acquire is new and I assume not many things are using it yet so the negative performance impact of making the pipe non-blocking isn't important yet.

try_acquire is new and I assume not many things are using it yet so the negative performance impact of making the pipe non-blocking isn't important yet.

Well cc is using it so it does have some effect to the ecosystem as a whole, though depending on the project, it might not be that large as compiling is much more expensive.

Opened rust-lang/libc#3760