4 ms·
Modern OS Xs appear to have two extra things to help with this: - kqueue_qos - lets you do an atomic poll+receive of a Mach message on a Mach port - EV_ONESHO
by to3m 10y ago
Modern OS Xs appear to have two extra things to help with this:
- kqueue_qos - lets you do an atomic poll+receive of a Mach message on a Mach port
- EV_ONESHOT - once you get the event, it's gone, and you have to reactivate it. I think this is the analogue to EPOLLEXCLUSIVE
I've used kqueue but both of these are new to me, so I could be wrong. (I'm pretty sure kqueue_qos didn't exist when I was doing this OS X stuff about a years ago. And I only had one waiting thread, so if I noticed EV_ONESHOT at the time, I didn't pay much attention to it.)
(Interestingly, EPOLLEXCLUSIVE promises to wake up "at least" one thread, suggesting that it might wake up all of them. Whereas EV_ONESHOT sounds like it will only wake up one - since once retrieved by one call to kqueue, the event will be canceled, and it will never be returned by another. But the Linux man page doesn't say what "at least" actually means... and, to be honest, the OS X one is barely any clearer anyway, AS USUAL. So who knows for certain without scraping through the source.)
- caf 10y agoThe "at least" is meant to convey that the API doesn't promise only one will be woken. It's very similar to the way that pthread_cond_signal() is documented by POSIX to wake at least one thread waiting on the condition variable, and for the same underlying reason.
- daniel02216 10y agoEV_ONESHOT refers to the individual kevent registration, and is basically an automatic EV_DELETE on delivery of the event. EPOLLEXCLUSIVE is acting at a different layer - in kevent terms it would cause only one of the registered kevents watching an object to be activated when the object is ready instead of all of the kevents watching for the same thing.
- caf 10y agoAnd there's a epoll() equivalent of EV_ONESHOT, EPOLLONESHOT.