From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 465 invoked by alias); 8 Jan 2003 03:27:19 -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 452 invoked from network); 8 Jan 2003 03:27:18 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 03:27:18 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18W8kW-0007G8-00; Tue, 07 Jan 2003 23:27:32 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18W6s4-0000AP-00; Tue, 07 Jan 2003 22:27:12 -0500 Date: Wed, 08 Jan 2003 03:27:00 -0000 From: Daniel Jacobowitz To: Dan Mosedale Cc: gdb-patches@sources.redhat.com Subject: Re: threads and target-function-calls Message-ID: <20030108032712.GA616@nevyn.them.org> Mail-Followup-To: Dan Mosedale , gdb-patches@sources.redhat.com References: <3E1B7829.6B6E8BAF@redhat.com> <20030108010842.GA30628@nevyn.them.org> <3E1B91B7.4010309@mozilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1B91B7.4010309@mozilla.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00318.txt.bz2 On Tue, Jan 07, 2003 at 06:49:27PM -0800, Dan Mosedale wrote: > Daniel Jacobowitz wrote: > > >On Tue, Jan 07, 2003 at 05:00:25PM -0800, Michael Snyder wrote: > > > > > >>Hey folks, > >> > >>Did you know that (at least on x86 linux), if you have a multi-thread > >>program and you execute a target function call, all the threads get to > >>run? Doesn't that seem like a bad thing? Wouldn't we really rather > >>only run the thread that is executing the target function call? > >> > >> > > > >Eeeeek! I think I agree with you here; that's the logical behavior. > >It never occured to me to try. > > > What happens if the target function wants to interact with another > thread? e.g. wait on a mutex being held by another thread? It'll deadlock; the user will Control-C; then he can either use "return" to cancel the call, or free the mutex himself, or whatever. Letting all threads just resume what they were doing doesn't seem to make sense in general... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer