Thread (13 messages) flat view 13 messages, 4 authors, 2015-03-14

Re: [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd

From: Andy Lutomirski <hidden>
Date: 2015-03-13 22:28:26
Also in: linux-fsdevel, lkml

On Fri, Mar 13, 2015 at 3:20 PM,  [off-list ref] wrote:
On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
quoted
On Fri, Mar 13, 2015 at 12:57 PM,  [off-list ref] wrote:
quoted
A process launching a new process with CLONE_FD is explicitly requesting
that the process be automatically reaped without any other process
having to wait on it.  The task needs to not become a zombie, because
otherwise, it'll show up in waitpid(-1, ...) calls in the parent
process, which would break the ability to use this to completely
encapsulate process management within a library and not interfere with
the parent's process handling via SIGCHLD and wait{pid,3,4}.
Wouldn't the correct behavior be to keep it alive as a zombie but
*not* show it in waitpid, etc?
That's a significant change to the semantics of waitpid.  And then
someone would still need to wait on the process, which we'd like to
avoid.  (We don't want to have magic "reap on read(2)" semantics,
because among other things, what if we add a means in the future to get
an additional file descriptor corresponding to an existing process?)
Do we not already have a state "dead, successfully waited on by
parent, but still around because ptraced"?  If not, shouldn't we?
Isn't that what PTRACE_SEIZE does?  Or am I just confused?

--Andy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help