This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] test-skeleton: Kill any child process's offspring
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 24 Sep 2013 23:09:14 +0100
- Subject: Re: [PATCH] test-skeleton: Kill any child process's offspring
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1309231748080 dot 4379 at tp dot orcam dot me dot uk> <20130924205922 dot C80012C08C at topped-with-meat dot com>
On Tue, 24 Sep 2013, Roland McGrath wrote:
> That seems reasonable. But if you do that, then you need to check the
> setpgid call for errors so we never kill the pgrp if it's not a fresh one.
Hmm, is setpgid (0, 0) allowed to ever fail (other than after setsid has
been already called, in which case the pgid will be the same as pid
anyway, and which test-skeleton doesn't do anyway)? From the way the
process group API has been defined I infer it cannot, however if I am
wrong for any reason, then I'll be happy to get enlightened. Also the
comment at the setpgid call we have in test-skeleton indicates we already
rely on the call to always succeed.
Please also note that fork(2) is not allowed to use a pid for the newly
created process that is the same as an existing pgid, which means that if
we use a pid returned from fork(2) as a pgid, then we'll never hit another
process group even if setpgid should fail for any reason.
Therefore I think any extra error handling for setpgid here would be a
case of over-engineering and would only obfuscate code unnecessarily (just
as would for example checking the return value from execve(2)).
Maciej