Boost logo

Boost :

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

      


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk