Subject: Re: [boost] [threads] Win32 Events on POSIX
From: Fu ji (fujimailing_at_[hidden])
Date: 2015-02-17 04:41:54
Ok guys after small debugging session it work's, I attached working code,
maybe someone want's to use it.
But I see that I started really interesting conversation. It is really hard
to port all funtionality of WFMO because you can put as parameters:
Change notification, Console input, Event, Memory resource notification,
Mutex, Process, Semaphore, Thread, Waitable timer.
So we can create unified API but that kind of flexibility always provide
performance penalty. I am not sure if something equivalent in Unix can be
implemented on low level.
2015-02-17 10:29 GMT+01:00 Rob Stewart <rob.stewart_at_[hidden]>:
> On February 16, 2015 11:00:25 PM EST, Andrey Semashev <
> andrey.semashev_at_[hidden]> wrote:
> > On Monday 16 February 2015 17:04:34 Rob Stewart wrote:
> > > 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:
> > > > >
> > > > > 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.
> > I was suggesting a way to monitor a process, as a better alternative
> > to pipes.
> Okay, but I was suggesting the idea of doing that together with waiting on
> synchronization primitives, which is the domain of WFMO().
> > > > However, I feel that in such cases specialized solutions or
> > > > Boost.ASIO would play better.
> > >
> > > Those would only apply to files, sockets, etc.
> > Boost.ASIO has support for any fd-based entities, and also can be used
> > to
> > invoke functions in the working threads. This covers pretty much
> > everything
> > you may need in order to synchronize with multiple event sources.
> It doesn't cover sync primitives.
> (Sent from my portable computation engine)
> Unsubscribe & other changes: