[cl-debian] Re: [Sbcl-devel] sbcl with sb-threads not compatible with 2.4 kernel

[Gábor Melis]

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