[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failing test case 67 Fatal errors but M4 continues producing output
From: |
Joel E. Denny |
Subject: |
Re: Failing test case 67 Fatal errors but M4 continues producing output |
Date: |
Sun, 11 Apr 2010 13:15:22 -0400 (EDT) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
Hi Bruno,
On Sun, 11 Apr 2010, Bruno Haible wrote:
> > pid = create_pipe_bidi ("m4", m4, (char **)(void*)argv, false, true,
> > true, filter_fd);
> > I thought that create_pipe_bidi is supposed to make sure
> > that the m4 subprocess is killed when Bison invokes exit
>
> No, there's no feature in Unix or in create_pipe_bidi that does such a
> cleanup.
> You need to do this cleanup yourself. For example, through an atexit
> call that registers a function that does
>
> pid_t pid = pid_of_running_child_process;
> if (pid != (pid_t)(-1))
> kill (pid, SIGTERM);
In the create_pipe_bidi invocation above, I set the slave_process argument
to true. create_pipe_bidi passes that argument to create_pipe, which then
invokes register_slave_subprocess, which uses atexit to register a
function that invokes kill.
Moreover the documentation in pipe.h, which contains create_pipe_bidi,
says:
If slave_process is true, the child process will be terminated when
its creator receives a catchable fatal signal or exits normally. If
slave_process is false, the child process will continue running in
this case, until it is lucky enough to attempt to communicate with
its creator and thus get a SIGPIPE signal.
> The tricky thing here is to make sure that you don't accidentally kill
> an unrelated process that got assigned the same PID after your child
> process exited.
When the child process exits, it becomes a zombie so that the parent can
safely reap it, so I didn't think the pid could possibly be reused before
the parent exits.
> > I might try the simple fix of draining the m4 output pipe before invoking
> > exit
>
> What would be the point of letting 'm4' consume CPU time once you know that
> you want to throw away its input anyway? Instead, I would just kill it.
Right, but I figured that killing it wasn't working properly on the
reported platform.
Re: Failing test case 67 Fatal errors but M4 continues producing output, Petr Machata, 2010/04/12