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-10 09:03:51

----- Original Message ----
> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Sent: Thu, February 10, 2011 3:31:00 PM
> Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library 
>starts tomorrow
> 
> Artyom wrote:
> >
> > > 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.
> 
> Sure, but the application  may have reasons to use it, too, and may use a 
>different signal API.
> 

Agree

> >  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
> >  b) You can't use wait in other parts of the code.
> >
> > Also you don't  have to steal the handler you can call it
> > (sigaction returns previous  handler).
> 
> Unfortunately, if the application installs a SIGCHLD handler  after 
>Boost.Process,
> it may not behave so well.  Perhaps the better scheme  is to provide a signal 
>handler
> and require the application to install it, within  the application's own scheme 
>and code.
> so that the handler's management is more  explicit.  You'd need to document the 
>need for the
> handler to  be installed  for dependent features to work, give example code for 
>how to
> install it in  cooperation with an application's own handler, and even provide 
>an API
> that does  the work for those applications that otherwise don't care about  
>SIGCHLD.

Yes I think this approach is good one.

In any case current Boost.Process way can't remain.

Other possible (but very wasteful) way to handle this if user
does not want to mess with signals and don't want them to happen
at all is to create a thread per asynchronous waiting that
calls waitpid() and detach it immediately it may be even
created with small stack size that does something like

  void *thread_func(void *) {
    ...
    waitpid(...)
    lock_some_shared_data
       if(io_service is still alive)
          io_service->notify_on_pid
       else 
          pass
    unlock_some_shared_data
  }

But this is actually  just in case user really does
not want to handle signals or don't want Boost.Process to
install signals for him.

Probably it would be ok to provide some parameter
on how to wait asynchronously:

typedef enum {
   wait_default,           // using thread+waitpid per-process on POSIX OS
   wait_using_sigaction,   // install signal handler
   wait_using_sigwaitinfo, // install signal handler
   wait_polling,           // poll all waiting pids for end, when
                           // requested - for example by user's signal
                           // handler
} wait_method_type;

void async_wait(pid ,method_type m = wait_default)
#ifdef BOOST_POSIX
void poll_handlers(); // check if child completed
                      // called by user when receives sigchld
endif

Artyom