Re: GChildWatchSource take three

["Alexis S. L. Carvalho" <alexis cecm usp br>]

Thus spake Owen Taylor:
> On Fri, 2003-08-01 at 16:53, Alexis S. L. Carvalho wrote:
> > If you decide to keep this function public, the docs should mention that
> > it should be called before the first call to fork (i.e. before the first
> > child is launched) - otherwise there's no point in calling it.
> 
> Hmm, if we think this is a problem, the API should not call the function
> implicitely, but *require* you to call it explicitely. Otherwise, you
> are inviting people to write buggy programs that usually work.

I Agree.

> But is this a real problem? How many programs are there out there that
> run a child process synchronously by forking a child and then 
> immediately calling waitpid() on it? How many of them worry that 
> SIGCHLD might be ignored?

Yeah, this is probably a minor issue, but if the programmer wanted to,
he could handle it.  If this initialization function is private, you
have to go behind GLib's back to do something about it.

> I think a parent program that leaves SIGCHLD as SIGIGN when forking
> a child is just buggy. Even glibc's system() implementation looks 
> vulnerable to this.

Buggy or malicious.  I'm just (a bit) worried about the second case.

> [ I wrote a short program to test system(), and it seemed to work 
> fine, but that may just be a race condition thing. ]

system() should block SIGCHLD.  Testing here indicates that this is
enough to bypass the special semantics of ignoring it.

Alexis