On Thursday 11 August 2005 23:21, Peter Van Eynde wrote:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301511&archive=yes
I quote: "Recent glibc switches to use NPTL instead of LinuxThreads when 2.6 kernel is used. If you set environment variable LD_ASSUME_KERNEL=2.4.1 and rerun his programs on 2.6 kernel, the problem is just disappeared (because LinuxThreads is used). Note that NPTL uses futex for mutex protection, instead LinuxThreads uses signal."
I've read the bug report twice and still don't understand what it means for us. It says that one can get caught out by calling non-reentrant glibc functions from signal handlers and if glibc uses nptl a likely symptom is blocking in a futex.
I traced the problem on a 2.4 kernel until the first nl_langinfo that blows up with a sigsegv, so it seems to possibly fit.
I traced the problem on a 2.4 kernel until the first futex call that returns with enosys and an endless stream of sigsegvs immediately after it.
So getting threaded sbcl to work again on 2.4 looks a little too difficult to do in the short amount of time I have available.
That I agree with. And it wouldn't be very surprising if it turned out that with linuxthreads linked in we don't have a chance at all.
Do people think it is better to have a sbcl that bombs out on 2.4 with "you should run 2.6" or should I drop the threading on x86?
Let me help, if you compile it with gcc4 then disable threading because it just doesn't work at all (or as well as when compiled with gcc3 :-)). If it is compiled with gcc3 then I'd go with threads and drop 2.4 support.
Groetjes, Peter
Cheers, Gabor