Re: Warning about reaped children

[Tim Janik <timj imendio com>]

On Thu, 29 Mar 2007, Federico Mena Quintero wrote:

> Hi,
>
> I forgot to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async_with_pipes()
> and ended up scratching my head about why my GChildWatch callback wasn't
> firing.  After some hot strace action and RTFM, I added that flag and
> everything worked perfectly.  Do we need a warning like the one in the
> attached patch?

the waitpid(2) manual page lists a fair number of (sometimes complicated)
cases where ECHILD might be returned. so basically, i'd say catching all
cases portably where check_for_child_exited() could possibly end up with
ECHILD is rather hard. that means, appling your patch could possibly result
in developers having to chase racy conditions on secondary platforms, and
that'd be counter productive.

alternatives that came to mind after i read your patch are:
- prominently mark the need for G_SPAWN_DO_NOT_REAP_CHILD in the docs to
  g_child_watch_add. but then i figured that is already the case (for
  child_watch and g_spawn_async*)...
  so maybe you have just ran into a sginificantly bad luck situation
  where a documented detail escaped you...?
- introduce a "diagnostics" logging level. this is an idea i've been
  pondering about for a while. basically, we could have something like
    g_diag (domain, format, ...);
  which does *not* produce any output by default, but will actually
  print messages if G_DEBUG=diag is set.
  and, these type of messages should always be compiled into programs
  and libraries, regardless of debugging mode. that way, developers
  can turn on extra diagnosis if they run into problems, and they
  can also instruct users to produce more information in debugging
  scenarios.
  the warning you have in your patch would be perfectly suitable for
  g_diag(), since most probably it'll be often useful, but seldomly
  bogus (and the latter condition is must-not-have for warnings,
  errors and assertions).

>  Federico

---
ciaoTJ