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
On February 16, 2015 11:00:25 PM EST, Andrey Semashev < andrey.semashev@gmail.com> wrote:
On Monday 16 February 2015 17:04:34 Rob Stewart wrote:
On February 16, 2015 8:21:01 AM EST, Andrey Semashev
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.
___ Rob
(Sent from my portable computation engine)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost