From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13667 invoked by alias); 18 May 2011 18:17:18 -0000 Received: (qmail 13656 invoked by uid 22791); 18 May 2011 18:17:17 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,FUZZY_AMBIEN,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 May 2011 18:17:04 +0000 Received: (qmail 12729 invoked from network); 18 May 2011 18:17:03 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 May 2011 18:17:03 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Workaround for 10970, 12702, avoid calling waitpid Date: Wed, 18 May 2011 18:17:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Jan Kratochvil , Doug Evans References: <20110517181920.7EE51246196@ruffy.mtv.corp.google.com> <20110517220751.GA14238@host1.jankratochvil.net> <20110518171311.GA13277@host1.jankratochvil.net> In-Reply-To: <20110518171311.GA13277@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105181916.59767.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00404.txt.bz2 On Wednesday 18 May 2011 18:13:11, Jan Kratochvil wrote: > + if (is_lwp (lp->ptid) && GET_PID (lp->ptid) == GET_LWP (lp->ptid) > + && linux_lwp_is_zombie (GET_LWP (lp->ptid))) When can is_lwp(lp->ptid) be false? > + if (pid != 0 && (pid == -1 && errno == ECHILD)) pid != 0 check looks redundant as is. Is it there to try to make this more readable? IMO, it isn't because whenever I read this, I'll stop and ponder whether there's a bug here, due to the redundancy. :-) FWIW, this looks good to me, but I wonder whether checking for zombieness after the waitpids wouldn't avoid a few /proc/ reads in the common case. The inferior exit code reported to the core/user will be the exit code of the last LWP that exits, instead of the leader's exit code. We've stepped out of C realm when the leader exited, so I'm not sure that matters (or how to make it be != 0, even). -- Pedro Alves