<div dir="ltr"><div>On Tue, Sep 16, 2014 at 3:17 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>> On Sep 16, 2014, at 12:55 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>><br>> 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).<br>><br>> 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.<br><br></span>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.<br></blockquote><div><br></div><div>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".</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 3:21 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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  </div></div></div></div>