I’ve been considering for a little while adding _umtx_op interfaces to kqueue, which I think would address these use cases and integrate with waiting for other kinds of events trivially (and not have the kinds of race conditions that the epoll-based attempts at this on Linux had). I’d love to understand a bit better what WINE wants with respect to threads being able to acquire a mutex / semaphore / whatever in these operations, versus just get a notification that they might be able to acquire them. It sounds as if the WFMO variant that attempts to consume all of them is quite rare, so a userspace wrapper that wakes if any of the synchronisation primitives is available and then tries to acquire them all and retries on failure is probably fine?
If anyone who works on WINE reads this, please send me a message. I’d love to discuss this more.
I’ve been considering for a little while adding
_umtx_opinterfaces to kqueue, which I think would address these use cases and integrate with waiting for other kinds of events trivially (and not have the kinds of race conditions that the epoll-based attempts at this on Linux had). I’d love to understand a bit better what WINE wants with respect to threads being able to acquire a mutex / semaphore / whatever in these operations, versus just get a notification that they might be able to acquire them. It sounds as if the WFMO variant that attempts to consume all of them is quite rare, so a userspace wrapper that wakes if any of the synchronisation primitives is available and then tries to acquire them all and retries on failure is probably fine?If anyone who works on WINE reads this, please send me a message. I’d love to discuss this more.