Comment by trentnelson
23 days ago
WaitForMultipleObjects is fascinating behind the scenes. A single thread can wait on up to 64 independent events, which is done by plumbing the KTHREAD data structure with literally 64 slots for dispatcher header stuff, plus all the supporting Ke/dispatcher logic in the kernel.
There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user space alone.
Yeah I was wondering if some native Linux apps might want to use it, since it is clearly useful and hard to emulate.
Linux native semaphores are enough. Linux has been able to be very performant without it. That feature seems like way too over engineered for little gains.
This comes up often, but what can it do that poll can't?
Reading the link provided by https://news.ycombinator.com/item?id=47511778, I believe "atomically acquire multiple objects". The link states they try to emulate it by performing a poll then a read, but the gap between those results in a race, which is a terrible thing to have in a synchronisation primitive.
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
Great post.
Ah, interesting, so wfm does both the wait and the acquire!
When using eventfd it is indeed annoying having to both poll and later read to disarm the object (there are epoll tricks that can be used but are not generalizable).
The signal+wait is also a primitive that it is hard to implement atomically on posix.