Re: The perl 5.10.0 headache
I haven't had an opportunity to run the test yet (my laptop currently
grinding away building the new release of GCC for m68k) but threads on Linux
when using linuxthreads to my knowledge are almost completely in userland;
linuxthreads uses clone() to create them. If it requires real-time signals
on kFreeBSD, then won't it in theory require a realtime Linux kernel to get
the same effect?
With non-rt behaviour of signals is possible to "drop" sent signals.
Pending signals are in kernel represented by bitmask, i.e. at most one
signal with given number is pending. The rt behaviour of signals uses
queue in kernel, i.e. there is no lost of pending signals.
The linuxthreads detect operating mode of signals. Under non-rt
behaviour it tries to count sent and received signals in userspace,
but there is a race condition, despite claims in lt code.
See pthread_restart, pthread_suspend, pthread_timedsuspend variants
in linuxthreads/pthread.c (comments claims rt variant is in linux kernel
since 2.2 series, soo FreeBSd have been really behind).
The wrong optimisation can lead to similar failures even with
signals queued by kernel.
You can test whether attached C code works in sarge and etch.
Petr
Reply to: