Date: Wed, 7 Aug 2002 10:53:06 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: eischen@pcnet1.pcnet.com Subject: Re: Help needed. Deadlock in rtld makes openoffice build hang ag Message-ID: <200208071753.g77Hr6Fs058407@vashon.polstra.com> In-Reply-To: <200208071636.g77GavpD003986@mail.pcnet.com> References: <200208071636.g77GavpD003986@mail.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200208071636.g77GavpD003986@mail.pcnet.com>, Daniel Eischen <eischen@pcnet1.pcnet.com> wrote: > > I agree completely about spinlocks vs. mutexes, in principle. But ... > > the reason the rtld uses its own spinlock implementation is because > > it cannot assume that the threads package is libc_r. It could be > > linuxthreads or some completely unknown threads package. I don't > > like the current solution in the rtld, but it's hard to come up with > > something that works with arbitrary threads packages. > > As long as all threads packages that we want to support have > pthread_mutex_lock/pthread_mutex_unlock, then you can just > use a weak reference to them (and pthread_mutex_init I guess > too) and use them when present. I tried something like that once, but I ran into a problem. When the rtld calls one of the application's locking functions, that function might reference a symbol which needs lazy binding. That results in a call back into the rtld, and the rtld locks against itself. I guess it's worthwhile revisiting that approach and trying harder to make it work. Ideally I'd just like to eliminate the need for locking at all when resolving symbols in the rtld. I think that's possible, but don't look for it any time real soon. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208071753.g77Hr6Fs058407>