From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31512 invoked by alias); 3 Oct 2005 22:01:22 -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 31499 invoked by uid 22791); 3 Oct 2005 22:01:20 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 03 Oct 2005 22:01:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EMYN2-0004s5-C6; Mon, 03 Oct 2005 18:01:16 -0400 Date: Mon, 03 Oct 2005 22:01:00 -0000 From: Daniel Jacobowitz To: Stan Shebs Cc: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20051003220116.GA18671@nevyn.them.org> Mail-Followup-To: Stan Shebs , Nick Roberts , gdb-patches@sources.redhat.com References: <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> <4341A4B4.8000601@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4341A4B4.8000601@apple.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00032.txt.bz2 On Mon, Oct 03, 2005 at 02:37:56PM -0700, Stan Shebs wrote: > 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. If Darwin's really got no non-blocking way to do this, then it'll need either threading, or a helper process which handles the blocking events and feeds them back to a file descriptor. Threading is probably easier, I agree. > >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. I can't see any immediate reason why the upper levels need to know about this. I still need to take a look at Nick's patch, though. -- Daniel Jacobowitz CodeSourcery, LLC