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

Subject: Re: [boost] [threads] Win32 Events on POSIX
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-02-16 08:21:01

On Monday 16 February 2015 06:47:00 Rob Stewart wrote:
> On February 16, 2015 3:58:08 AM EST, Andrey Semashev 
<andrey.semashev_at_[hidden]> 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.