On Tue, Sep 16, 2014 at 3:17 PM, Greg Clayton <gclay...@apple.com> wrote:
> > > On Sep 16, 2014, at 12:55 PM, Zachary Turner <ztur...@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 <gclay...@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
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
