From owner-freebsd-current@FreeBSD.ORG Tue May 20 21:37:24 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF39037B401; Tue, 20 May 2003 21:37:24 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1805043FBF; Tue, 20 May 2003 21:37:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-uinj8tt.dialup.mindspring.com ([165.121.163.189] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19ILLv-0006OF-00; Tue, 20 May 2003 21:37:23 -0700 Message-ID: <3ECB023B.40666E3D@mindspring.com> Date: Tue, 20 May 2003 21:36:11 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a071f992b5bdcba3965835548e10a28d667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: re@FreeBSD.org cc: Robert Watson cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 04:37:25 -0000 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