HadrienG2
commented
8 years ago As an alternative to events for this kind of scenarios, it has been suggested to have a synchronization primitive with more states, each of which can be monitored. An example for this would be a progress counter on which notifications can be set when a certain progress level is reached.
Another option would be pulse events, i.e. events that reset once all listeners have completed. But that model has issues on its own, such as making polling much less straightforward.
Asynchronous libraries are extremely reliant on the availability of nonblocking IO, and nonblocking system calls in general. When one attempts to limit the amount of threads to the amount of CPU cores, a blocking thread is essentially a lost CPU core, and this must not happen.
Unfortunately, nonblocking IO is also much of a mess today. All attempts to standardize it, such as POSIX.1b or boost::asio, have ended up having extremely OS-specific behavior and performance characteristics. This means that this project will probably have to devise its own set of nonblocking primitives, at least for common use cases (logging, file I/O, networking...).
In addition to the benefit to users, this proposal is also beneficial to the project as a library since it will stress the limits of the event synchronization primitive, which is quite well suited to situations where a clear notion of completion exists, but not as appropriate when dealing with continuous processes such as streamed data processing.