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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-02-10 08:31:00

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.

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

> > It should be really the application and not external
> > libraries which manage signals. As there can be even more
> > problems like blocked signals using Boost.Process could
> > affect a program in ways a developer would probably not even
> > think about.
>
> I think if you state this clearly in documentation it is OK as
> SIGCLD is "Unix" way to wait for child.

Documentation can certainly justify the library when the application fails to follow the prescribed form and gets unwanted behavior, but that doesn't help the wayward developer solve the application bug.  It seems better for the library to not function as desired without explicit action from the application than to silently work in some scenarios and not others.  That would drive the developer to the documentation to learn why the desired feature isn't working.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.