From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17984 invoked by alias); 3 Oct 2005 21:39:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17967 invoked by uid 22791); 3 Oct 2005 21:39:00 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 03 Oct 2005 21:39:00 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j93Lbsvh021275; Mon, 3 Oct 2005 14:37:54 -0700 (PDT) Received: from [17.219.209.63] (unknown [17.219.209.63]) by relay5.apple.com (Apple SCV relay) with ESMTP id 969D032401C; Mon, 3 Oct 2005 14:37:52 -0700 (PDT) Message-ID: <4341A4B4.8000601@apple.com> Date: Mon, 03 Oct 2005 21:39:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution References: <17142.56731.941946.838268@farnswood.snap.net.nz> <20050808130516.GA9046@nevyn.them.org> <17160.63891.324530.937796@farnswood.snap.net.nz> <430B9BF8.500@apple.com> <17188.60739.749026.738477@farnswood.snap.net.nz> <17198.37622.443418.520082@farnswood.snap.net.nz> <17216.38283.618507.704220@kahikatea.snap.net.nz> <20051003131829.GA19106@nevyn.them.org> <17217.34460.753468.405145@kahikatea.snap.net.nz> <20051003203108.GA15652@nevyn.them.org> In-Reply-To: <20051003203108.GA15652@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00029.txt.bz2 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