Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

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.  
>IMHO
> > 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
io_services. 

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 
>features.
> But if I had to choose between  the current implementation of 
>boost::process::status,
> 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 :-)

Artyom