Problem would be rather missing memory barier, or non-atomic operation.
This should be fixable even with 2.5 glibc and linuxthreads.
Do we need a fix in linuxthreads, or the kernel?
I don't know.
The linuxthreads add-on is currently used
by hppa and kfreebsd-* for glibc 2.7.
But the latest entry in linuxthreads ChangeLog is dated 2006-10-31.
So codebase might be even the same as with your 2.5-11 glibc.
On GNU/kFreeBSD, the test fails with 6.x (FreeBSD) kernel, it passes with
7.x kernel (after I added runtime detection of presence of rt
capable FreeBSD kernel). It is due to realtime behaviour of signals, in
7.x they properly queue in kernel. I assume 2.6 linux kernel (and may
be also 2.4) even on 68k queues them properly.
IMHO, the problem is not in pthread add-on, but lies somewhere else,
i.e. non-atomic operation, wrong optimization by gcc, ...
I suggets to use attached C code and try strace and so on.
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
