FreeBSD pthread_equal "bug"

Terry Lambert tlambert2 at mindspring.com
Thu Jun 5 10:13:28 PDT 2003


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


More information about the freebsd-threads mailing list