From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 20:40:21 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DED8916A4CE for ; Tue, 8 Jun 2004 20:40:21 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5D1C43D45 for ; Tue, 8 Jun 2004 20:40:21 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 73AAFFD03A; Tue, 8 Jun 2004 13:40:21 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83102-04; Tue, 8 Jun 2004 13:40:21 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id E6FE3FD031; Tue, 8 Jun 2004 13:40:20 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: <1086724856.83077.13.camel@server.mcneil.com> References: <1086724856.83077.13.camel@server.mcneil.com> Content-Type: text/plain Message-Id: <1086727220.83494.10.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 13:40:20 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: Joe Marcus Clarke cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 20:40:22 -0000 On Tue, 2004-06-08 at 13:00, Sean McNeil wrote: > On Tue, 2004-06-08 at 12:15, Daniel Eischen wrote: > > On Tue, 8 Jun 2004, Sean McNeil wrote: > > > I fail to see why this is opposed by the FreeBSD community, the reasons > > > behind the opposition, or why this entire thread has started trying to > > > work around the mistake of making them weak symbols instead of just > > > fixing the underlying problem by making them strong references. > > > > Because there is no problem if you link correctly. And I > > would like to be able to override libc functions with my > > own. I wish malloc was weak. I wish all our exported > > symbols were weak. By the way, you are imposing a requirement of linking pthread in a particular order to that you can override the symbols in libc (just like pthread wants to) and yet do not wish to impose a linking order on this ficticious other need you have? Why not make pthread libc overrides strong? You have made them so for things like _pthread_join, so why not for select and all those? I have an alternative proposal for you: make the libc symbols like the pthread ones.... Taking select as an example, Make libc and pthread both have weak references to __select for select. Make libc have a weak reference to __libc_select for __select. Implement __libc_select in libc and __select in pthread. Sean