[lgg]

I am a fan of io_uring style interfaces and think fork() is completely busted, but I agree that intuitively the comparisons seem to obfuscate where a lot of the perf wins come from

1. posix_spawn() performance seems terrible on Linux. There is just no excuse for it to be worse than vfork()... I know on Linux it is implemented in library code, but on macOS it is a syscall, which achieves most of the stated benefits of io_uring_spawn (batching up all the posix_spawn_actions and then handing them down to the kennel in a single syscall).

2. Again, I think the whole "hope posix_spawn supports the actions you need" is a bit overblown here. It is not like io_uring supports operations for every single syscall that exists either. People keep holding up the lack of some operation in posix_spawn() as a justification for designing a new interface. Just add some new flags and actions (see posix_spawn_file_actions_addchdir_np(), POSIX_SPAWN_SETEXEC, or POSIX_SPAWN_CLOEXEC_DEFAULT on macOS for examples).

Obviously posix_spawn() is a synchronous operation, so in that respect io_uring_spawn is inherently a bit faster for processes that want to asynchronously launch processes, but if Linux implemented posix_spawn() like macOS did then you could achieve the same thing just by adding support for issuing a posix_spawn() operation via io_uring just like any other operation.

Given that io_uring has a lot of momentum and is getting broad support for various operations it probably does make sense to implement io_uring_spawn and then layer posix_spawn() on top of it as proposed in the talk, but I wish the slides called out that a lot of performance gains seem (at least me) to have little to do with the nature of io_uring and more to do with that fact that posix_spawn() is implemented purely in userspace on Linux and can't batch the existing actions because of that.