[lldb-dev] Process spawning and shutdown

[Zachary Turner]

The only way to wait for a process to exit is calling WaitForSingleObject()
with the handle. You can specify a timeout to that function, and INFINITE
is one possible value.  However, it seems like the primary use case for
LLDB waiting for a process to exit is to fire off the exit callback
asynchronously.  In that case Windows, like other platforms, will probably
need to create a background thread, then WaitForSingleObject() on the
background thread, then fire the callback after it returns.

What I was thinking is have the HostProcess provide a method called
BlockUntilExit() which can be used anywhere (even from the main thread)
should the caller desire it, but when launching a process we would create a
thread for on each platform that just calls this method on the HostProcess,
then issues the callback.  This would unify alot of code currently spread
across the different Host.[cpp/mm] files.

One thing that still eludes me though, is that when processes are launched
using Applescript, no monitoring thread is created, and it looks at least
like the callback is never invoked on these processes.  Is this by design,
a bug, or am I misreading the code?

On Mon, Sep 22, 2014 at 11:15 AM, Greg Clayton <gclayton at apple.com> wrote:

> So you can get the exit status of a process using
>
> BOOL WINAPI GetExitCodeProcess(_In_ HANDLE hProcess, _Out_  LPDWORD
> lpExitCode);
>
> Is there a way to wait for the process to exit without polling? Or do you
> have to keep calling GetExitCodeProcess() until STILL_ACTIVE is not
> returned? I am guessing you can wait on the hProcess handle somehow?
>
> Anyway, it seems like we want the following when launching processes:
>
> 1 - a way to wait for a process to finish with an optional timeout (which
> defaults to infinite)
> 2 - a way to say, no need to wait for the process to finish
>
> For 1, we do what we are currently doing. The process monitor callback for
> windows will need to wait for the process to exit, then call
> GetExitCodeProcess() when done and return the value. On unix machines, we
> will reap the process and return the exit status.
>
> For 2, windows doesn't need to do anything, but we still need to reap the
> process on unix to avoid zombies.
>
> Not sure if I missed any scenarios?
>
> Greg
>
>
> > On Sep 22, 2014, at 9:33 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > Yes, but closing the handle is semantically a different operation than
> reaping a process.  You can close a handle to a process while the process
> is still running and it doesn't affect anything except that it frees up
> space in your process's handle table.  You can also not close a handle, and
> if the process exits nothing bad will come of it.  So closing the handle is
> more tied to the lifetime of the instantiated HostProcess , and independent
> of the actual process running on ths system.
> >
> > On Sun, Sep 21, 2014 at 11:40 PM, Matthew Gardiner <mg11 at csr.com> wrote:
> > On Wed, 2014-09-17 at 00:27 -0700, Zachary Turner wrote:
> >
> > > I know Join isn't really the right word, but there's no concept of
> > > reaping a process on Windows.
> >
> > However, on Windows, isn't there still a requirement to CloseHandle that
> > handles returned by CreateProcess?
> >
> > Matt
> >
> >
> >
> >
> >
> > Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> > More information can be found at www.csr.com. Keep up to date with CSR
> on our technical blog, www.csr.com/blog, CSR people blog,
> www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> > New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140922/344010ea/attachment.html>