Re: RFC: MI output during program execution

[Stan Shebs <shebs@apple.com>]

Daniel Jacobowitz wrote:

>On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote:
>
>>Daniel Jacobowitz writes:
>> > Sorry, miscommunication.  You don't need approval to create a branch;
>> > go right ahead.
>>
>>OK. Thanks.
>>
>> > I violently dislike the idea of linking gdb with pthreads.  I'm
>> > confident that we can get the benefits without that, however.  I've got
>> > this patch sitting in my queue of things to play with.
>>
>>I know this will sound stupid but what is the alternative? Using fork?
>>
>
>Doing it "asynchronously" through the GDB event loop, which is I
>believe the same way we handle remote async targets.  All in one
>process.
>
Remote async can do it (more-or-less) portably because both the user
and target interaction happen through file descriptors, and the usual
API supports multiplexing. Darwin is problematic because you have
to get some data from events and the like that only have blocking
calls to monitor, so you need a thread per blocking syscall.

>
>This is a little more complicated to design, however, it's got less
>complexity at runtime.  I've spent enough of my life using GDB on
>systems where pthreads didn't work that I don't want to make GDB
>dependent on them.
>
Ideally you'd push the thread/multiplex decision down into target code,
but this would be a semi-ambitious rework to event-loop.c. It might
not matter though, if Darwin (and other configs maybe) can keep using
their own thread-hell code, while something like Linux can assume file
descriptors for inferior monitoring and thus use the general mechanism.

Stan