> 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
