Date: Thu, 05 Jun 2003 09:59:14 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" Message-ID: <3EDF76E2.E06C3003@mindspring.com> References: <Pine.GSO.4.10.10306051209090.230-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Thu, 5 Jun 2003, Terry Lambert wrote: > > So's not explicitly protecting dlopen(), and so's not forcing > > I never committed anything that protected dlopen(), and > > rescheduling of the thread that was running at preemption time, > > when returning from an involuntary preemption. ;^). > > also never committed anything to do this either. > > The rtld-elf fixes were not specifically related to dlopen(). > Binding of objects was not thread-safe even if dlopen() was not > used. I'm surprised; I thought this was being done explicitly for dlopen() support. For just the regular use of shared libraries, a trivial workaround is to change the behaviour from RTLD_LAZY to RTLD_NOW, which would ensure that all bindings are completed beforeany threads are started (at least, until .init sections or static constructors for C++ objects in some libraries end up starting threads). I was aware that you had been holding off on the scheduling, but the rtld changes being made seemed schitzophrenic with regard to an overall policy of not making changes to protect applications from their programmers. If this is the case, I withdraw my objections to the ld.so changes to support locking and/or an order of operation change. I still think it's an optimization to avoid RTLD_NOW behaviour on shared library startup, more than anything else, but it's a reasonable optimization. You learn something new every day... -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EDF76E2.E06C3003>