Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030572AbVKXBCi (ORCPT ); Wed, 23 Nov 2005 20:02:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030574AbVKXBCh (ORCPT ); Wed, 23 Nov 2005 20:02:37 -0500 Received: from mail.dvmed.net ([216.237.124.58]:23943 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1030572AbVKXBCg (ORCPT ); Wed, 23 Nov 2005 20:02:36 -0500 Message-ID: <43851116.9060103@pobox.com> Date: Wed, 23 Nov 2005 20:02:14 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Daniel Jacobowitz , Alan Cox , "H. Peter Anvin" , Andi Kleen , Gerd Knorr , Dave Jones , Zachary Amsden , Pavel Machek , Andrew Morton , Linux Kernel Mailing List , Zwane Mwaikambo , Pratap Subrahmanyam , Christopher Li , "Eric W. Biederman" , Ingo Molnar Subject: Re: [patch] SMP alternatives References: <1132764133.7268.51.camel@localhost.localdomain> <20051123163906.GF20775@brahms.suse.de> <1132766489.7268.71.camel@localhost.localdomain> <4384AECC.1030403@zytor.com> <1132782245.13095.4.camel@localhost.localdomain> <20051123214835.GA24044@nevyn.them.org> <20051123222056.GA25078@nevyn.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Linus Torvalds wrote: > The third alternative is to know at link-time that the process never does > anything threaded, but that needs more developer attention and > non-standard setups, and you _will_ get it wrong (some library will create > some thread without the developer even realizing). It also has the > duplicated library overhead (but at least now the duplication is just > twice, not "each process duplicates its own private pointer") [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 26 Linus Torvalds wrote: > The third alternative is to know at link-time that the process never does > anything threaded, but that needs more developer attention and > non-standard setups, and you _will_ get it wrong (some library will create > some thread without the developer even realizing). It also has the > duplicated library overhead (but at least now the duplication is just > twice, not "each process duplicates its own private pointer") Small data point: In a lot of gcc-related build processes, the configure/makefile junk passes '-pthread' to the compiler/linker. So a lot of programs in Linux distros are already built this way. The bigger problem is with libraries, which cannot know ahead of time whether the app is threaded or not, and therefore must assume threaded. A few libs do things like glibc, others (like GLib) have an explicit mylib_thread_init() called at program startup. Jeff - 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/