5.1-RELEASE TODO

[Terry Lambert]

John Baldwin wrote:
> >> According to chapter 12 of the "Go Solo 2" book, this is a bogus thing
> >> to do.  Callers are required to take a critical section over the calls
> >> to the dl* functions because the dlerror() function uses a static buffer
> >> that can be overwritten in a multi-threaded environment.
> >
> > Sadly, that insight doesn't seem to have influenced the development
> > practices of a number of major application vendors :-(.
> 
> As Peter has mentioned before, simply locking calls to dlopen() in the
> application is not sufficient since every time you have to resolve a
> symbol when doing a call to a function for the first time, you hit the
> same data structures and need the locks in those cases as well.  Assuming
> I recalled all that correctly.

That's an order of operations problem, not a locking problem.  Just
like a lot of the simple queue.h structures that are unnecessarily
being locked around modificiations because the macros aren't being
rewritten to make the updates atomic.

It's a really bad idea to imply a locking policy in something as
fundamental as the runtime linker code, unless you expect to be
able to replace the primitives at compile/link/runtime at some
point.

-- Terry