Re: [boost] [threads] Win32 Events on POSIX

On Monday 16 February 2015 06:47:00 Rob Stewart wrote:

On February 16, 2015 3:58:08 AM EST, Andrey Semashev wrote:

...

On Monday 16 February 2015 08:30:58 Fu ji wrote:

...

Thank you for the reply. I see that you have almost all

functionality done,

...

I miss only something equivalent to WaitForMultipleObjects it is in

your

...

plans for the future functionality ?

On POSIX systems this is only achievable with select() & co., which in turn implies that synchronization primitives must be fd-based. I currently have no plans for implementing that, mostly because I recon that such primitives would have worse performance in the normal use (i.e. when a single primitive is used for thread synchronization).

Performance isn't the only criteria by which to judge an API. The ability to wait on multiple synchronization primitives can be helpful in some cases regardless of performance. Obviously if performance is an issue, that must be documented.

Using the Windows API one also can wait on other handles, like process handles, and not just sync primitives. The same is possible using select if one opens a pipe or socket to the other process, since closing the other process will close its end of the IPC.

I think sigwait or signalfd are better suited for this.

If a select()-based wait on sync primitives is possible, then a portable WaitForMultipleObjects() is possible and would be handy in one's toolbox.

In my experience performance tends to be the defining factor in thread synchronization primitives. I have a few real world cases where I would like to use WaitForMultipleObjects but at the same time I want the best performance there, including when there is only one thread and no actual synchronization needed. I chose not to use select/poll/epoll in those cases for this reason, and I would have made the same decision for WaitForMultipleObjects if it was a wrapper around them. I realize that my experience is not the whole world, and there may be situations where performance is not a concern. However, I feel that in such cases specialized solutions or Boost.ASIO would play better.