The Hub Event (working title) is similar to the standard Win32 Event Object, but multiple consumers (clients) of the event can reliably wait on them, while being set/reset by the producer.
When the software requires to signal/release all waiting threads, each exactly once, that are not necessarily in a single process. Where naïve approach would be to use the flawed PulseEvent API and the system does not already have established IPC by other means (IOCP).
The implementation is somewhat heavy for what it does, but I haven't figured out simpler one. Perhaps I'll get some ideas for v2 here. In fact I believe this thing should be provided as a another kernel object by the OS alongside events, semaphores, mutexes, etc.
When the software requires to signal/release all waiting threads, each exactly once, that are not necessarily in a single process. Where naïve approach would be to use the flawed PulseEvent API and the system does not already have established IPC by other means (IOCP).
The implementation is somewhat heavy for what it does, but I haven't figured out simpler one. Perhaps I'll get some ideas for v2 here. In fact I believe this thing should be provided as a another kernel object by the OS alongside events, semaphores, mutexes, etc.