Re: GChildWatch source -- take two

[Jonathan Blandford <jrb redhat com>]

"Alexis S. L. Carvalho" <alexis cecm usp br> writes:

> If you mean special casing -1|0 so that it just installs the signal
> handler, it may be better to just make g_child_watch_init public to
> avoid magical values.  This should avoid this kind of race.

No, I meant to have g_child_watch_add(-1) have the same effect as
calling waitpid(-1).  That is to say, it'll give notice of every child
process that exits.  g_child_watch_add(0) will give notice of children
in the process group, just as waitpid(0) does.  With this behavior, it
makes more sense to check the return value of the call.

However, you've convinced me to make g_child_watch_source_init public as
well.

> It'd probably be pretty hard to safely uninstall the handler - either
> the programmer or GLib would have to guarantee that there are no
> GChildWatchSources pending.
> 
> Oh, speaking of initialization functions, I think
> g_child_watch_source_init is not safe against two threads calling
> g_child_watch_source_new for the first time at the same time.

Gotcha.  This is doubly a problem if it's made public.

> > > I don't think this has to be volatile.
> > 
> > It wasn't originally.  I just put it in to make Alex feel better. (-;
> 
> I think he meant the global child_watch_count that is modified in
> the signal handler.

I missed that in his comment.  It's sig_atomic_t now, which should be
volatile anyway.

> > > Now the bad news:  I'm afraid I wasn't able to run your child-test
> > > correctly.  I don't really know the internals of GMainLoop, but if I
> > > understood correctly, it was always the thread running in main that
> > > called waitpid.  It always failed with ECHILD (No child processes).
> > 
> > I may have sent a bogus copy of child-test.c in retrospect.  Let me
> > attach another copy instead.
> 
> Same problem: the thread that calls waitpid is the one that runs in the
> function main, and because of bugs in LinuxThreads it can't wait for the
> children of the other threads.

Oh ugh.  I only tried this on an NPTL system.

> This one is going to be pretty hard (if not impossible) to fix in the
> general case:  if a thread runs a child and then exits before the child,
> the child is reparented to init and no SIGCHLD is delivered.

Argh!!!!!  I don't see how to fix that at all. )-: 

I suppose this is one of those cases where we have to punt
non-workingness to documentation.  That being said, it doesn't seem like
you can get this working with or without glib, so by using the source
you don't lose anything.  It is still a little disheartening.

Thanks,
-Jonathan