From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8344 invoked by alias); 9 Mar 2004 06:36:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8330 invoked from network); 9 Mar 2004 06:36:36 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 9 Mar 2004 06:36:36 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1B0aqF-00056A-QW; Tue, 09 Mar 2004 01:35:52 -0500 Date: Tue, 09 Mar 2004 06:36:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: cagney@gnu.org, Ulrich.Weigand@de.ibm.com,gdb@sources.redhat.com In-reply-to: <20040309025255.GA11922@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 8 Mar 2004 21:52:55 -0500) Subject: Re: getpid after vfork broken in recent glibc Reply-to: Eli Zaretskii References: <404D2EB9.10607@gnu.org> <20040309025255.GA11922@nevyn.them.org> X-SW-Source: 2004-03/txt/msg00064.txt.bz2 > Date: Mon, 8 Mar 2004 21:52:55 -0500 > From: Daniel Jacobowitz > > > > We might as well simply always use fork -- the "performance" benefit is > > hardly valid any more (Hmm, perhaps something related to this is why > > vfork never worked, and hence was disabled, on HP/UX). > > Since I went to some trouble to make "shell escape" use vfork when > possible (2003-06-21), I have to disagree with your assumption. When > GDB is using a good-sized chunk of the RAM on a system, forking > unnecessarily is a real pain. > > Given the idiotic definition of vfork, though, I guess we don't have a > choice. How about if glibc did us a small favor and invalidated its cached PID on a vfork?