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

Subject: Re: [boost] [threads] Win32 Events on POSIX
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-02-16 17:04:34

On February 16, 2015 8:21:01 AM EST, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> 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. 
> > 
> > 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.

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)