From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30217 invoked by alias); 8 Jan 2003 00:34:26 -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 29772 invoked from network); 8 Jan 2003 00:33:10 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 8 Jan 2003 00:33:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 265F03D06; Tue, 7 Jan 2003 19:33:01 -0500 (EST) Message-ID: <3E1B71BC.8010009@redhat.com> Date: Wed, 08 Jan 2003 00:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] lin-lwp.c prelim changes for new thread model References: <3E1A14C5.77F6C2DF@redhat.com> <20030107033133.GB5132@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00307.txt.bz2 >> The minimal change I propose below is as follows: >> When we send kill(SIGSTOP) to all the threads, we now include >> the event thread, where previously we had made him a special case. >> That way, whether in the new model or the old one, we can now do >> a waitpid on every thread including the event thread. >> >> What do you think? > > > To be honest, I don't like this very much. You're hurting performance > in the current case (whose performance is already quite bad enough, > thank you!). I don't think that the additional complexity/waiting is > worthwhile. Just an aside, At present GDB does ~60 system calls per multi-threaded single step (see previous discussion related to ptrace), these extra two calls may easily prove to be in the noise. Given the thread has already stopped, they should be close to kernel no-ops. When commenting on performance, the thing that is always needed is hard data either supporting or dismissing any claim. Andrew