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.
Greg > On 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. > >> 2) Processes need to be reaped when they exit so as not to leave zombie >> processes. > > Yes. > >> >> 3) Some places want to have a user-specified callback executed >> asynchronously in an arbitrary thread context when a process exits. > > Yes. This is true for processes we debug. When we launch llgs or debugserver > we want to know if the process ever dies so we can kill our debug session in > case it does. These are both user specific callbacks. > >> >> Does this cover everything? There's currently alot of built in assumptions >> about which platforms want what subset of the above functionality, but I >> think I'm starting to get a pretty good handle on this code and have a good >> idea of how to restructure it to be more platform-agnostic. Want to make >> sure I understand all the primary use cases first though. > > We need to: > 1 - always reap child processes we spawn > 2 - allow a specific function to optionally get called when a process does > get reaped so the exit status of the process can be passed along > > The AppleScript is so we can implement: > > (lldb) process launch --tty -- /bin/ls .... > > The "--tty" option launches the process in its own terminal window. The only > way to do this right now is via AppleScript on MacOSX. Since it runs in a > terminal, it will get reaped by the terminal when it exits, thus the "no need > to reap these processes". > > We launch processes currently via the host layer right now: > > static Error > LaunchProcess (ProcessLaunchInfo &launch_info); > > The launch_info contains the ability to provide a reap callback with > SetMonitorProcessCallback(). > > Launching might allow for launching via a specified launch method (fork/exec, > posix_spawn, LaunchServices (MacOSX), backboard (iOS specific), Windows > launching, etc. So the launch methods should be pluggable and a default > method should be used on a host when no options are specified. > >> >> On Tue, Sep 16, 2014 at 11:55 AM, Zachary Turner <ztur...@google.com> wrote: >> The last major piece of the Host layer I'd like to address is process >> launching and cleanup. From looking over the code it seems we have the >> following different ways to launch a process: >> >> MacOSX: >> * Applescript >> * XPC >> * posix_spawn >> >> Other posix variants: >> * posix_spawn >> >> Windows: >> * Native windows launcher >> >> >> Among these, there are a couple of different ways to reap processes on exit >> and/or "join" on them. These are: >> >> MacOSX: >> * Applescript [ No process reaping or monitoring occurs. ] >> * XPC [ Uses MacOSX-specific dispatch library for >> monitoring ] >> * posix_spawn [ Uses MacOSX-specific dispatch library for monitoring ] >> >> Other posix variants: >> * posix_spawn [ Launches a background thread to monitor for process >> exit, join on the thread to join on the process ] >> >> Windows: >> * Native windows launcher [ WaitForSingleObject ] >> >> A few questions: >> >> 1) Is Join() on a process a useful operation that people would be interested >> in seeing implemented for all platforms? >> >> 2) On Linux at least, if you don't waitpid() on a process you'll end up with >> zombies. It seems this is true on MacOSX as well, because I see waitpid() >> in StartMonitoringChildProcess. Is this not true for the Applescript >> launcher? Why doesn't the Applescript launching code path call >> StartMonitoringChildProcess() anywhere? >> >> 3) Speaking of the Applescript launcher, what is it and what is it used for? >> >> >> I'll probably have more questions as I wrap my head around this a little >> more. Thanks >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
