Paul Pluzhnikov schrieb:
Bernhard Ibertsberger <[EMAIL PROTECTED]> 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
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
