Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262406AbUFEVNZ (ORCPT ); Sat, 5 Jun 2004 17:13:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262418AbUFEVNZ (ORCPT ); Sat, 5 Jun 2004 17:13:25 -0400 Received: from fw.osdl.org ([65.172.181.6]:43702 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S262406AbUFEVNU (ORCPT ); Sat, 5 Jun 2004 17:13:20 -0400 Date: Sat, 5 Jun 2004 14:13:12 -0700 (PDT) From: Linus Torvalds To: Arjan van de Ven , Ulrich Drepper cc: Russell Leighton , Kernel Mailing List Subject: Re: clone() <-> getpid() bug in 2.6? In-Reply-To: <20040605205547.GD20716@devserv.devel.redhat.com> Message-ID: References: <40C1E6A9.3010307@elegant-software.com> <20040605205547.GD20716@devserv.devel.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1028 Lines: 30 On Sat, 5 Jun 2004, Arjan van de Ven wrote: > > ... or glibc internally caches the getpid() result and doesn't notice the > app calls clone() internally... strace seems to show 1 getpid() call total > not 2. Why the hell does glibc do that totally useless optimization? It's a classic "optimize for benchmarks" thing - evil. I don't see any real app caring, and clearly apps _do_ fail when you get it wrong, as shown by Russell. And it's really easy to get it wrong. You can't just invalidate the cache when you see a "clone()" - you have to make sure that you never ever cache it ever after either. Uli, if Arjan is right, then please fix this. It's a buggy and pointless optimization. Anybody who optimizes purely for benchmarks should be ashamed of themselves. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/