Boost logo

Boost :

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-02-11 02:07:34

> > [...]I think if you can't implement this properly just don't implement.
> > it is important to have less features that work then half working
> > onces.
> I agree (although for a different but somehow related reason; the complexity
> of the implementation bothers me more).

IMHO it is not as complex as it may look like, there already was bunch
of possible solutions in this thread.

Async wait is very valuable feature.

> > [...]
> >> However I don't think using SIGCHLD is a good idea.
> >> As a library developer I don't really want to steal the
> >> signal handler for any signals as we have no idea if there
> >> are other parts in a program which actually wait for SIGCHLD, too.
> >
> > SIGCHLD is used for wait operation on the child to exit, it is its
> > purpose.
> >
> > So it is better to state in the documentation that it uses SIGCHLD
> > then to say that
> >
> > a) Only one io_service can do async waiting
> You have the same problem with a SIGCHLD-based implementation.
> If an io_service installs a signal handler you can't use a second
> io_service as it would install a new signal handler.

I had already suggested that you need a singletone "waiter" thread
that would use sigwaitinfo that would allow to do the job
for any number of io_services. Note it would even allow to
execute installed signal handlers if you need them and notify

asio is very well designed asynchrous event loop that IMHO
should be used for any asynchronous operations as it allows
to do in "async" way almost any task.
> > [...]I think if you state this clearly in documentation it is OK as
> > SIGCLD is "Unix" way to wait for child.
> Here's a new proposal:
> We remove boost::process::status. While it's tempting to use Boost.Asio

See comment above.

> I come to the conclusion that it isn't and can't be the framework
> of choice for all asynchronous operations. When I think about my
> attempts to create a Boost.Asio extension to handle signals
> I feel only confirmed.

It is not straight forward as signal unlike select/epoll/kqueue is
process resource and naturally should be handled in single location.

But it is notification only issue, Asio provides you event loop
that allows dispatch various asynchronous events and it is very
valuable and such notifications can be integrated to Asio.

> Then Boost.Process would give up the goal of supporting only cross-platform
> But if I had to choose between the current implementation of
> a library with no support at all to wait for child processes and a
>non-asio-like class
> to handle signals I'd choose the latter.

I don't think that the fact that it is not as straight forward on POSIX platform
as on Windows platform you should give up.

I come from Unix world and If I was thinking this way then 99% of my project
would not support Windows :-)



Boost list run by bdawes at, gregod at, cpdaniel at, john at