How to report a death by signal ? (was: loopwhilex)

From: Laurent Bercot <ska-skaware_at_skarnet.org>
Date: Wed, 18 Feb 2015 02:16:24 +0100

  OK, I want to tackle this problem once and for all, because it
has been gnawing at the edges of my mind for some time, and Olivier
forced me to look it in the face, and it's not pretty.

  The situation is this: we have a parent process P (itself child
of a grandparent process G) spawning a child process C and waiting
for it. Either C dies normally with an exit code from 0 to 255, or
it is killed by a signal.
  I want P to report to G what happened to C, with as much precision
as possible.

  The problem is, there's more information in a wstat (the
structure filled in by wait()) than a process can report by
simply exiting. P could exit with the same exit code as C, but
then what should it do if C has been killed by a signal ?

  An idea is to have P kill itself with the same signal that killed C.
But that's actually not right, because P itself could be killed by a
signal from another source, and G needs that information. "P has been
killed by a signal" and "C has been killed by a signal" are two
different informations and should be reported in a different way.

  So, any way you look at it, there is always more information than we
can report.
  Is there a satisfactory way to proceed ?

  If P knows that C will not be using the whole range of valid exit
codes, it can reserve one to report the death of C by a signal. But
if P does not know, or if C actually uses the whole range ?
  There has to be some information loss somewhere, and that is
annoying me. Any thoughts ?

  Note that "foreground" has it easy: it does not need to report
information to its parent by exiting, it just needs to report
information to the process it execs into - which is trivially
done via the environment. The "?" environment variable can hold
a whole wstat's worth of information, and more; so it's a non-issue
for foreground.

-- 
  Laurent
Received on Wed Feb 18 2015 - 01:16:24 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC