[lldb-dev] Process spawning and shutdown

[Todd Fiala]

> The biggest example is currently llgs, which has posix-y stuff all over
and which will be quite difficult to port to Windows as a result

I think at least some of that issue is going to revolve around it's
adherence to the gdb-remote RSP protocol.  That has a number of elements in
it (particularly stop notifications) that are inherently POSIX-focused.

-Todd

On Wed, Sep 17, 2014 at 12:51 AM, Zachary Turner <zturner at google.com> wrote:

> Sorry, hit send too soon.
>
> Exposing native OS primitive types like lldb::thread_t, lldb::process_t,
> and raw file descriptors to generic code means that people will use them in
> ways that aren't actually generic, and this can already been seen in many
> places.  The biggest example is currently llgs, which has posix-y stuff all
> over and which will be quite difficult to port to Windows as a result, if
> and when we get there.  There are other examples too though.
>  Platform-specific ideas have made it into the public API, such as
> SBHostOS::ThreadDetach, and are used in other places as well, such as a
> reliance on TLS destructors (Timer) and thread cancellation.  There's also
> select() being used on file descriptors, and probably many things I haven't
> even found yet.
>
> I can go fix all of these things on a case-by-case basis, and originally
> that was my strategy.  But as I found more and more examples of it, I
> started thinking that I want to prevent this type of code from showing up
> in the future.  I searched for the thread but was unable to find it,
> where Jim (apologies if I'm misquoting or misremembering) said that when
> the Host layer was originally written, there was not sufficient time to sit
> down and design something future-proof, and that you guys just had to get
> it working.  So what I was (and have been) trying to accomplish was exactly
> that.  Obviously, such large changes are not without risk, and can create
> headaches and introduce bugs, although I think that once the bugs are
> resolved the entire codebase and all platforms will benefit from improved
> code health as a result.
>
> Ultimately if you don't think these type of changes add value, or you
> don't think it's an improvement, then that's that.  It's much easier for me
> to write code just for Windows and not have to worry about getting stuff
> working on 3 different platforms that I have varying levels of familiarity
> with.  I don't think it's necessarily easier in the long term though, as
> there will still be no clear separation between generic and platform
> specific code, and new things will continue to turn up where an assumption
> was made that something was generic when it wasn't.
>
>
>
> On Wed, Sep 17, 2014 at 12:27 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>> On Tue, 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.
>>>
>>
>> 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 <gclayton at 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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/ec37993a/attachment.html>