[lldb-dev] Process spawning and shutdown

Zachary Turner zturner at google.com
Wed Sep 17 00:27:54 PDT 2014


On Tue, Sep 16, 2014 at 3:17 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Sep 16, 2014, at 12:55 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > Just a follow-up.  It seems like there are three use cases for the
> StartMonitoringChildProcess code-path (poorly named, since FreeBSD and
> linux process plugins also have a ProcessMonitor class leading to great
> confusion).
> >
> > 1) Some places want to Join() on a process exiting.  They currently do
> this by calling Join() on a HostThread returned by
> StartMonitoringChildProcess, but the important thing is just that they want
> to join, not how it's implemented.
>
> Join is not the right word. Reap() is the correct word. Join is just seen
> because you might spawn a thread whose sole purpose in life is to reap a
> child process. When you launch a shell command, you want to spawn the
> process and wait for it to get reaped. If you debug a process, you need to
> reap your child process if you launch it, but you won't ever call join on a
> thread that is waiting for it.
>

I know Join isn't really the right word, but there's no concept of reaping
a process on Windows.  My understanding is that on posix, "reaping"
specifically refers to ensuring that zombie processes don't linger and
waste system resources which is a logically different operation than "wait
for this process to exit", even though certain operations that reap also
wait for the process to exit as a means to an end.  So I'm using join for
lack of a better term to refer specifically to "wait for this process to
exit".


On Tue, Sep 16, 2014 at 3:21 PM, Greg Clayton <gclayton at apple.com> wrote:

> I would really like to see the Host::LaunchProcess fixed for windows and
> fix the reaping to just work for windows. I would like to avoid large
> changes that aren't needed. All of the AppleScript stuff and other details
> are fine to stay hidden within the MacOSX specific version of
> Host::LaunchProcess() as long as the contents of the ProcessLaunchInfo are
> obeyed.
>

I had been working on creating a HostProcess abstraction similar to the
HostThread abstraction that I created.  I think that there's alot of value
in having a robust set of OS abstractions that can be used by lldb,
debugserver, and other processes alike.  Exposing native OS primitive types
like lldb::thread_t and lldb::process_t to generic code
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/682e15d3/attachment.html>


More information about the lldb-dev mailing list