Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Ingham <jingham@apple.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Nick Roberts <nickrob@snap.net.nz>,
	        Michael Snyder <Michael.Snyder@palmsource.com>,
	        Mark Kettenis <mark.kettenis@xs4all.nl>,
	gdb@sources.redhat.com
Subject: Re: Merge of nickrob-async-20060513 to mainline?
Date: Thu, 31 Aug 2006 23:59:00 -0000	[thread overview]
Message-ID: <5716A2FD-4565-4B29-8E26-1FD0290C2ACC@apple.com> (raw)
In-Reply-To: <20060831233703.GA21723@nevyn.them.org>

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


      reply	other threads:[~2006-08-31 23:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30  2:27 Nick Roberts
2006-08-30  2:33 ` Daniel Jacobowitz
2006-08-30  3:21   ` Nick Roberts
2006-08-30  4:01     ` Daniel Jacobowitz
2006-08-30 12:31       ` Eli Zaretskii
2006-08-30 21:34       ` Nick Roberts
2006-08-30 21:43         ` Daniel Jacobowitz
2006-08-30 23:45           ` Nick Roberts
2006-09-26  8:41           ` Nick Roberts
2006-09-26 12:38             ` Daniel Jacobowitz
2006-09-26 22:12               ` Nick Roberts
2006-09-26 22:24                 ` Daniel Jacobowitz
2006-09-26 23:40                   ` Nick Roberts
2006-09-29  1:50                   ` Nick Roberts
2006-10-06  0:53               ` Nick Roberts
2006-10-06  1:26                 ` Daniel Jacobowitz
2006-10-06  2:13                   ` Nick Roberts
2006-10-06  3:24                     ` Daniel Jacobowitz
2006-10-08  3:46                       ` Nick Roberts
2006-10-09 18:00                         ` async implies sync, was " Michael Snyder
2006-10-09 20:28                           ` async implies sync Nick Roberts
2006-08-31 21:03     ` Merge of nickrob-async-20060513 to mainline? Mark Kettenis
2006-08-31 21:49       ` Nick Roberts
2006-08-31 22:29         ` Daniel Jacobowitz
2006-08-31 22:40           ` Nick Roberts
2006-08-31 22:53             ` Michael Snyder
2006-08-31 23:33               ` Nick Roberts
2006-08-31 23:37                 ` Daniel Jacobowitz
2006-08-31 23:59                   ` Jim Ingham [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5716A2FD-4565-4B29-8E26-1FD0290C2ACC@apple.com \
    --to=jingham@apple.com \
    --cc=Michael.Snyder@palmsource.com \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=nickrob@snap.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox