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

On February 16, 2015 8:21:01 AM EST, Andrey Semashev 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

...

...

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.

Using the Windows API one also can wait on other handles, like

On Monday 16 February 2015 06:47:00 Rob Stewart wrote: primitive 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.

Those only apply to monitoring signals. The desire here was to wait on multiple things including sync primitives.

...

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.

Those would only apply to files, sockets, etc. You may be right that performance is paramount for many use cases, but that doesn't mean others require it, so denying support for those use cases may be heavy handed. Having said that, my use cases for WFMO()'s have been limited, so it could be just as well to not provide it. There are other ways to make things work in the absence of WFMO(). ___ Rob (Sent from my portable computation engine)