Hi Joel,
Joel E. Denny wrote:
> > input.y: fatal error: too many arguments for @output directive in skeleton
> > +/usr/bin/m4:./skel.c:175: ERROR: copying inserted file: Broken pipe
> > +/usr/bin/m4: write error
>
> Thanks for the report. One of the goals of Bison 2.4.2 was to avoid m4's
> report of a broken pipe. To do so, we started using gnulib's
> create_pipe_bidi, and that worked for me, but apparently it did not work
> in general.
>
> Here's the invocation of create_pipe_bidi:
>
> pid = create_pipe_bidi ("m4", m4, (char **)(void*)argv, false, true,
> true, filter_fd);
With the parameters to create_pipe_bidi, you influence whether the parent
process will signal errors or not. The child process' behaviour depends
on that program ('m4' in this case).
> The scenario is that Bison sometimes reaches a fatal error and thus
> invokes exit without reading all of the m4 output and without invoking
> wait_subprocess.
Then it's normal that m4 complains about the gone-away parent process to
which it wanted to deliver output.
> 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. In Unix, when the parent process of some process dies, the
process number 1 becomes its parent, and the child process is not even
notified about it.
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);
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.
> 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.
Bruno
