From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16106 invoked by alias); 29 Aug 2002 22:48:37 -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 16099 invoked from network); 29 Aug 2002 22:48:35 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 29 Aug 2002 22:48:35 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7TMZSU05581; Thu, 29 Aug 2002 17:35:28 -0500 To: Daniel Jacobowitz Cc: Michael Snyder , Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: RFA: gdb/568, messy thread exits References: <20020731163910.GA5622@nevyn.them.org> <20020812161447.GA770@nevyn.them.org> <200208132200.g7DM03vH034786@elgar.kettenis.dyndns.org> <20020813221350.GA14555@nevyn.them.org> <3D6AD68B.B6018428@redhat.com> <20020827013914.GA10015@nevyn.them.org> From: Jim Blandy Date: Thu, 29 Aug 2002 15:50:00 -0000 In-Reply-To: <20020827013914.GA10015@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg01015.txt.bz2 Daniel Jacobowitz writes: > I don't think so, but I don't have complete information. For one > thing, the next major LinuxThreads revision seems to have slipped > beyond the next major glibc release; for another, given all the work > Ingo Molnar's been putting in on minimal-overhead clone() and scalable > scheduling for this new library, I doubt he'd advocate wedging multiple > threads into a process. But the development is not happening in > public, so I don't really know. If I followed the thread correctly, I think I've heard Uli say that he's basically abandoned the M-on-N threads implementation, basically because he can't get the support he wants from the kernel. Uli and the kernel people disagree on how far the kernel should go to support pthreads. Everyone agrees that glibc and Linux together ought to correctly implement the pthreads interface. Correctness isn't at issue. But they disagree on whether Linux should provide special support to make pthreads more efficient. Ingo's position is that people who really want speed should use the non-portable kernel interfaces directly, and that people using portable interfaces should expect less-than-optimal performance. Providing optimal support for every random API some standards group has invented will complicate the kernel far too much. The groups really working on performance (databases; web servers) will all use the non-portable interfaces, and give good benchmarks on real-world applications. Uli's position is that most people will use the portable interfaces, so (I may be filling in here) it benefits more people to improve their performance.