[lldb-dev] Process spawning and shutdown

[Greg Clayton]

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 <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. 
> 
>> 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 <zturner at 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 at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>