Re: deadlock in NPTL, FUTEX

[Bernhard Ibertsberger]

Paul Pluzhnikov schrieb:
> Bernhard Ibertsberger <elgringo@gmx.at> writes:
>
> > since Kernel 2.5 signals seems to contain some trickier
> > pitfalls. "Native POSIX Threads Library" vs linuxthreads-0.10
>
> This isn't new to NPTL; you could have encountered the exact same
> deadlock with LinuxThreads.

Yes, you are right. But running [1] and [2] like

LD_ASSUME_KERNEL=2.4.1: ./ctime-hang

does not show a deadlock. Why does it behave like that? This is what i 
meant with "anatomy of the deadlock". Why does the same program show a 
deadlock by using NPTL and run fine with LinuxThreads?
(If NPTS vs. LinuxThreads is really the root of the matter...)

> > * where is the context between localtime() und vsprintf()?
>
> Huh? You seem to use words like "context" and "anatomy" in a meaning
> that is entirely unfamiliar to me.

OK, maybe "connection" would be a better word. I can't find how 
vsprintf() is been called by localtime().

> What further information do you need?

It was your demo and the hint to the term "async-signal safe", that 
gave me a good insight!
Though it does not explain why the deadlock depends on the kernel version.

>   int x;
>   void foo() { while (x) sleep(1); x+=1; sleep(60); x-=1; }
>
> Do you understand that
[..]

Now i do! Thanks a lot!

> Stdout *is* thread safe, and so is printf. But printf is not
> async-signal safe, and may deadlock if called from a signal
> handler. Solution: don't do that.

Yes Sir!

thx
Bernhard