Tcl Error (child process lost (is SIGCHLD ignored or trapped?)

[SS]

I want to discuss a tcl behavior in case tcl application has registered its own SIGCHLD handler.
In our system we have registered our SIGCHLD handler in which we are reaping child process with waitpid.
It seems currently this is an error scenario if application's SIGCHLD handler has reaped all the child process. (Including process launched by tcl exec) and throws an error "child process lost (is SIGCHLD ignored or trapped?)" (File generic/tclPipe.c function : TclCleanupChildren) .
Is there any way so that we can avoid this error? Why this is an error not warning if tcl child process is already reaped by application?

Thanks
SS

[Donal K. Fellows]

On 07/01/2015 12:52, SS wrote:
> I want to discuss a tcl behavior in case tcl application has
> registered its own SIGCHLD handler.

The only signal handler that Tcl installs is for SIGPIPE (and that's a
simple SIG_IGN). It does reset all signal handlers immediately before it
calls execve() when building a pipeline, but that's all.

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[SS]

So for tcl is it a problem if user stalls his own SIGCHLD signal handler?

On Wednesday, 7 January 2015 21:01:28 UTC+5:30, Donal K. Fellows wrote:
> On 07/01/2015 12:52, SS wrote:
> > I want to discuss a tcl behavior in case tcl application has
> > registered its own SIGCHLD handler.
>
> The only signal handler that Tcl installs is for SIGPIPE (and that's a
> simple SIG_IGN). It does reset all signal handlers immediately before it
> calls execve() when building a pipeline, but that's all.
>
> Donal.
> --

> Donal Fellows -- Tcl user, Tcl maintainer, TIP editor.

[Alexandre Ferrieux]

In fact, Tcl calls waitpid() in two contexts:

- in Tcl_ReapDetachedProcs(), which is a poor man's ersatz of SIGCHLD handler (without actually using signals: called on pipeline creation and closure, as a reasonably sampled spot in fork-intensive scripts). In this case it is waitpid(WNOHANG), and will not raise any error since it is in some sense a background task (and detached processes are by definition not to be tracked closely).

- in TclCleanupChildren(), which is the point where we want to know about the fate of the processes in a pipeline. Hence it is blocking, and cares about the returned status. Clearly this part depends on the fact that nobody has pulled the rug by calling waitpid() earlier.

To address your concern without an overhaul of core APIs, I can only imagine inserting some abstraction layer between Tcl_WaitPid and your handlers.

In an ideal world, Tcl would (1) use signal handlers more readily and (2) expose some API to overload its own, like SIGCHLD. The bad interactions (in a portable perspective) of threads and signals unfortunately made us drift pretty far from this.

So, it would seem reasonable to say that your best bet is to ignore the error raised by TclCleanupChildren. Sorry.

-Alex

[Donal K. Fellows]

On 08/01/2015 12:24, SS wrote:
> So for tcl is it a problem if user stalls his own SIGCHLD signal handler?

Now that would depend on what the signal handler is doing, yes?

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[Alexandre Ferrieux]

On Friday, January 9, 2015 at 2:21:36 PM UTC+1, Donal K. Fellows wrote:
> On 08/01/2015 12:24, SS wrote:
> > So for tcl is it a problem if user stalls his own SIGCHLD signal handler?
>
> Now that would depend on what the signal handler is doing, yes?

Uh, you're right, sorry for overlooking that one. If the handler can be taught to refrain from calling waitpid() on the processes Tcl is interested in (which are the jobs in the pipeline), the error can be avoided. But that's still a bit more complex than ignoring an error result ;-)

-Alex