Re: deadlock in signal handler with NPTL

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jun 23, 2004 at 08:56:35AM +0200, Thorsten Kukuk wrote:
> > I have reviewed all the changes to
> > lowlevellock.h since and I do not see any change that would effect this. In
> > fact your test case should show that same hang there.
> 
> The difference is: glibc with linuxthreads compiled only uses the
> locking, if the program is linked against pthread.
> 
> glibc with NPTL compiled always uses locking (__libc_lock_lock always
> calls lll_lock).
> 
> Uli, Jakub, is this really necessary? Wouldn't it be better to add the
> one extra compare?

This is done on purpose.  We are not going to sacrifice speed for the sake
of a few broken apps which work with linuxthreads by pure luck.
The reasons are actually both speed and being able to dlopen libpthread.so.
When syslog enters its critical section by __libc_lock_lock (syslog_lock);,
it really assumes that it is alone there, if it knew it can handle the
critical section being entered recursively, it could use
__libc_lock_lock_recursive instead (at which point your testcase would
probably work, unless there are other problem places).
But the code is clearly not prepared for that.
So, when the locks are nop in linuxthreads, e.g. openlog might be done
twice, or the outer syslog might believe it is connected while the inner
syslog closed it and similar problems.

	Jakub