Re: Merge of nickrob-async-20060513 to mainline?

Jim Ingham
2006-08-31T23:59:21Z

Optionally adding another thread if a given platform needs it is
actually pretty straight-forward to do as things stand. The event
stuff is designed to be able to accept an arbitrary number of event
sources. If you need an extra thread, you just hook up a pipe between
it an the main thread, and add the pipe to the select sources. The
ordinary event stuff handles waking up and calling the handler for
that source.

We do that for macosx - creating & hooking up the thread in
create_inferior and tearing it down in mourn_inferior. That part of
it is fairly simple.

And yes, we really do have to have the extra thread. The only way to
get "mach exceptions" - which are the ur-signals on Mac OS X and which
we need to capture - is a blocking API. So if we want to run gdb
asynchronously, we have to use an extra thread for the mach exceptions.

Jim

On Aug 31, 2006, at 4:37 PM, Daniel Jacobowitz wrote:

> On Fri, Sep 01, 2006 at 11:31:14AM +1200, Nick Roberts wrote:
>>>> It's their choice to make GDB multi-threaded. I'm just saying
>>>> it's an
>>>> example of where it seems to work in practice.
>>>
>>> Nick, what you're up against is that this is an old discussion.
>>> We've tossed around the idea of making gdb a multi-threaded app
>>> for years, and for various reasons, we've decided against it.
>>
>> If it's an old discussion, it was presumably before NPTL, when
>> LinuxThreads
>> was used.
>
> More likely it was before Linux was a relevant platform at all. GDB
> isn't all about GNU/Linux.
>
> Anyway, I don't see the point in worrying about this. We'll try to
> come up with an interface that lets an extra thread, if necessary,
> be contained to native files on platforms that really need it due to
> quirks of their debug interface; I vaguely recall hearing that Darwin
> was such a platform.
>
> I don't think any of the other native debug interfaces I'm familiar
> with qualify.
>
> --
> Daniel Jacobowitz
> CodeSourcery