Date: Tue, 08 Jun 2004 13:00:56 -0700 From: Sean McNeil <sean@mcneil.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached Message-ID: <1086724856.83077.13.camel@server.mcneil.com> In-Reply-To: <Pine.GSO.4.10.10406081505050.3616-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10406081505050.3616-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-06-08 at 12:15, Daniel Eischen wrote: > On Tue, 8 Jun 2004, Sean McNeil wrote: > > 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. > > This is wrong. Most of the shared libraries in ports only > want to be thread-safe, yet they still link to libpthread. > > > 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. > > There are not many (if any) of these libraries, but if there > are, then applications using those libraries should link to the > threads library of their choice. > > > 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 > > They should care, especially since you can choose different > thread libraries. You are talking about two different things. With linking, they don't care as everyone should be linking to pthread when required. If the application doesn't use pthread directly, it shouldn't link with pthread. If it directly links to a library that uses pthread, then the linker will take care of that. What you are talking about is afterwards. You can select what library it uses via. libmap.conf. > > 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. > > 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. You are imposing a requirement that is not necessary. There is no reason why apache2 should have to link the main application to pthread if, for some reason, a module that you have selected requires threading. Same thing for any application that might use plugin modules. I know you have this desire to override symbols in libc. I'm not saying you can't do that. It is a security risk, but it is very useful and I would say "yes, make malloc a weak symbol". Make everything in libc weak if you want. There should be a way to enforce ownership of functions, however. pthread really needs to enforce ownership. It needs to say "I have select and use that instead of the libc version". It should not matter if libpthread was linked in a particular order. It should not matter if pthread wasn't directly linked to the application at all. If select is a strong reference, then it doesn't. I would also propose a library that enforces libc's versions of functions. One that says "I was linked in and I say libc owns this function. No one else can override it." This would be a very good security tool. > See my earlier email for the advantage of not having shared > libraries linked to thread libraries (easier usage of > libmap.conf). We are in total agreement on this when it comes to libraries that are just "thread safe" yet do not do anything thread-specific. However, it would be even more useful and reliable to be able to tell libmap.conf that "ORBit library should use libc_r" and have all applications that pull in ORBit end up with the libc_r threading library. Sean
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086724856.83077.13.camel>