I went through that LKML thread and it looks like that particular patch isn't going anywhere, but given the general direction of supporting all syscalls in io_uring, I'm confident it will happen eventually.
Support for wait, in particular, would be strictly more powerful than waitv: you could wait for futexes and IO (or any other completions) at the same time!
It would. On the other hand, I never had a need to wait for futexes and IO at the same time. If I need an internal wakeup while blocked on a poll call, I would use an eventfd. YMMV.
In any case generalized support for all or most syscalls in io_uring can only be a good thing. Especially if we get eBPF support for chaining.
I'm also quite excited for the new intel instruction to send IPIs from userspace. That would be great for non blocking io_uring.
I don't think Windows has the equivalent of futex2, waiting on multiple addresses. WaitOnAddress() in Windows is the equivalent of futex, waiting on a single address.
WaitForMultipleObjects() in Windows is for acquiring multiple locks, not for waiting on arbitrary addresses. The parameters to WaitForMultipleObjects() are mutex/semaphore/event/etc handles. When WaitForMultipleObjects() returns, the ownerships of the locks are actually acquired. E.g. for semaphore, the count is decremented by WaitForMultipleObjects().
Futex2 is more generic where it just waits on multiple arbitrary addresses. The locking is done separately.