Sounds good to me. It's nice living in the future and being able to
rely on things like signalfd!
- Dan
p.s. I wrote a man page of sorts for that waaaay back in the past,
before it existed:
http://lkml.indiana.edu/hypermail/linux/kernel/0106.3/0404.html
On Wed, Aug 5, 2009 at 12:12 PM, Adam Langley<a...@chromium.org> wrote:
>
> Our child process reaping is a little bit of a hack right now, which
> is my fault. I didn't anticipate how bad it would turn out.
>
> Currently, we use a bunch of hacks to make sure that we reap all the
> children that we need to, but don't reap children from another part of
> the code etc. If we need to make sure that a process dies within x
> seconds, then we fork off a thread etc. process_util_posix.cc is scary
> complex and bodgy.
>
> Here's my plan:
>
> We have a singleton object in base which handles all forking and reaping:
>
> class ChildProcessReaper {
> public:
> // Has the same semantics as fork() - i.e. this function returns twice. In
> // the parent process, the resulting child will be reaped on exit and the
> // termination state will be saved. It can be accessed using
> // GetTerminationState() below.
> pid_t ForkAndRetainTerminationState(uint64_t* child_id);
>
> // Same as ForkAndRetainTerminationState, but the child's termination state
> // will not be retained on exit.
> pid_t ForkAndForget(uint64_t* child_id);
>
> // Get the termination state of a child started with
> // ForkAndRetainTerminationState(). If the child has terminated, then ths
> // function will return true and *status is set to the value obtained from
> // wait(2).
> bool GetTerminationState(uint64_t child_id, int* status);
>
> // Wait |seconds| seconds for the given child to terminate. If it doesn't
> // terminate within that amount of time, send SIGKILL. Calling this function
> // is a no-op if the child has already terminated. If the child was created
> // with ForkAndRetainTerminationState, then calling this function means that
> // the child's terminate state will no longer be retained.
> void EnsureChildTerminates(float seconds, uint64_t child_id);
>
>
> This object is created in the IO thread of the browser. On Linux it'll
> create a signalfd to get SIGCHILD. On OS X it'll spawn off a
> PlatformThread which sits in wait(2) for child notifications. We can
> then ensure that we'll never get zombies.
>
> The only wrinkle is that we need to return both a pid_t and another id
> (uint64_t above). Consider the following situation:
>
> 1) Thread A forks off a child, pid $x
> 2) The child runs, terminates and is reaped
> 3) Thread B forks off a child. Because $x has been reaped the kernel
> is free to reuse that pid
>
> Now, both thread A and B can call EnsureChildTerminates with pid $x
> and kill the wrong child.
>
>
> Any thoughts?
>
> AGL
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
