From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14120 invoked by alias); 31 Aug 2006 23:59:21 -0000 Received: (qmail 14111 invoked by uid 22791); 31 Aug 2006 23:59:21 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Aug 2006 23:59:19 +0000 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k7VNwfda026378; Thu, 31 Aug 2006 16:58:41 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay7.apple.com (Apple SCV relay) with ESMTP id 25F04E; Thu, 31 Aug 2006 16:58:41 -0700 (PDT) Date: Thu, 31 Aug 2006 23:59:00 -0000 Content-Transfer-Encoding: 7bit Cc: Nick Roberts , Michael Snyder , Mark Kettenis , gdb@sources.redhat.com From: Jim Ingham In-Reply-To: <20060831233703.GA21723@nevyn.them.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Subject: Re: Merge of nickrob-async-20060513 to mainline? References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> <17653.930.196634.143646@kahikatea.snap.net.nz> <200608312102.k7VL2TAe017778@elgar.sibelius.xs4all.nl> <17655.22749.599881.560771@kahikatea.snap.net.nz> <20060831222942.GA19065@nevyn.them.org> <17655.25836.313498.847320@kahikatea.snap.net.nz> <1157064793.4466.52.camel@localhost.localdomain> <17655.28994.979830.876998@kahikatea.snap.net.nz> <20060831233703.GA21723@nevyn.them.org> To: Daniel Jacobowitz Mime-Version: 1.0 (Apple Message framework v840) Message-Id: <5716A2FD-4565-4B29-8E26-1FD0290C2ACC@apple.com> X-Mailer: Apple Mail (2.840) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00298.txt.bz2 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