Bernhard Ibertsberger <[EMAIL PROTECTED]> writes: >> 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.
On your machine, for the limited number of tries. ctime-hang *does* deadlock on my machine every time, using either NPTL or LinuxThreads. > Why does it behave like that? When you perform operation, results of which are undefined, any outcome is possible, including apparently correct execution. > 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. LD_ASSUME_KERNEL does *not* change kernel version (you need a reboot for that). What it may do is select a different version of glibc, with different timing and different code layout, and these differences may allow the bug to hide better. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
