Date: Tue, 20 May 2003 21:36:11 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO Message-ID: <3ECB023B.40666E3D@mindspring.com> References: <XFMail.20030520163731.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECB023B.40666E3D>