Date: Tue, 08 Jun 2004 12:00:51 -0700 From: Sean McNeil <sean@mcneil.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached Message-ID: <1086721251.44183.14.camel@server.mcneil.com> In-Reply-To: <Pine.BSF.4.21.0406080104460.19288-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0406080104460.19288-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-06-08 at 01:05, Julian Elischer wrote: > On Tue, 8 Jun 2004, Daniel Eischen wrote: > > > [ trimmed to threads@ ] > > > > On Tue, 8 Jun 2004, Joe Marcus Clarke wrote: > > > > > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > > > > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > > > > > > > > > > > > Up front, I'd like to make a few apologies: > > > > > > > > > > 1) I am sorry for the length of this email. > > > > > 2) Although some very valid opinions have been expressed, I respectfully > > > > > have to disagree. This email will hopefully strengthen my position. > > > > > > > > Please stop spamming multiple lists. > > > > > > > > No, I don't want to litter all our thread libraries with strong references. > > > > As I've said before, build your shared libraries correctly so they don't > > > > bring in the threads library. > > Can you explain to me in words of 1 sylable why libpthread should not > have strong symbols? I haven't been following this argument.. As far as I can tell, there is no good reason. So far, there has been a lot of talk about how to deal with threading because of this very issue. Here is how threads were designed to work on all other platforms: If a shared library wants to be thread-safe, they include CFLAGS definitions for any include file magic that may have to be done. They do not link the shared library to the libpthread library. If a shared library is using threads (create, join, etc.) then they still do the CFLAGS defs but they also link to the pthread library. An application would link to the libraries they desire to use. They don't care if some library they use pulls in pthread or not. They only care when the application itself uses threads. If it is a direct library dependency, the linker would make the application depend on pthread. For instance, libORBit02.so.0 might be used by a gnome application, but it doesn't need to know or care that ORBit uses threads. libc functions should be global symbols in libpthread that override the functionality usually provided by libc. 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. Sean
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086721251.44183.14.camel>