Andreas Fuchs asf@boinkor.net writes:
I'm not entirely sure which of SBCL or SLIME needs to be fixed. Either SBCL should start including :sb-futex on its *feature* list again (or some other feature saying that threads are non-broken on this lisp build), or SLIME should stop checking for :sb-futex (which will break on SBCLs older than 0.8.21).
If it's possible given the time constraints and cvs tagging activity, I'd be happy if the preferred-communication-style checked only :sb-thread, and if the slime release notes for 1.2 required an sbcl of 0.8.21 or later.
Would that be OK with you guys? Sorry for the eleventh-hour (or even later) change request...
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
Andreas Fuchs asf@boinkor.net writes:
I'm not entirely sure which of SBCL or SLIME needs to be fixed. Either SBCL should start including :sb-futex on its *feature* list again (or some other feature saying that threads are non-broken on this lisp build), or SLIME should stop checking for :sb-futex (which will break on SBCLs older than 0.8.21).
If it's possible given the time constraints and cvs tagging activity, I'd be happy if the preferred-communication-style checked only :sb-thread, and if the slime release notes for 1.2 required an sbcl of 0.8.21 or later.
Does :sb-thread reasonably imply a working threads implementation? My only concern is that if SBCL on some platforms would have :sb-thread by default but not a reliable implementation, i.e. if SLIME suddenly starts using threads by default on platforms where it shouldn't.
Luke Gorrie luke@synap.se writes:
Christophe Rhodes csr21@cam.ac.uk writes:
If it's possible given the time constraints and cvs tagging activity, I'd be happy if the preferred-communication-style checked only :sb-thread, and if the slime release notes for 1.2 required an sbcl of 0.8.21 or later.
Does :sb-thread reasonably imply a working threads implementation? My only concern is that if SBCL on some platforms would have :sb-thread by default but not a reliable implementation, i.e. if SLIME suddenly starts using threads by default on platforms where it shouldn't.
I think (Dan reads this list, so he'll correct me if I'm wrong) that from 0.8.21 :sb-thread implies the previous combination of :sb-thread and :sb-futex before. That said, there is a possible snafu where an sbcl with :sb-thread will nevertheless refuse to start new threads if the underlying kernel is insufficiently futexed.
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
I think (Dan reads this list, so he'll correct me if I'm wrong) that from 0.8.21 :sb-thread implies the previous combination of :sb-thread and :sb-futex before.
Sounds to me like a good change to make for 1.2. What say you Helmut, shall we move the tag forward (cvs tag -F)?
Luke Gorrie luke@synap.se writes:
Christophe Rhodes csr21@cam.ac.uk writes:
I think (Dan reads this list, so he'll correct me if I'm wrong) that from 0.8.21 :sb-thread implies the previous combination of :sb-thread and :sb-futex before.
Sounds to me like a good change to make for 1.2. What say you Helmut, shall we move the tag forward (cvs tag -F)?
Yes, that's ok with me.
Helmut.
Christophe Rhodes csr21@cam.ac.uk writes:
Luke Gorrie luke@synap.se writes:
Christophe Rhodes csr21@cam.ac.uk writes:
If it's possible given the time constraints and cvs tagging activity, I'd be happy if the preferred-communication-style checked only :sb-thread, and if the slime release notes for 1.2 required an sbcl of 0.8.21 or later.
Does :sb-thread reasonably imply a working threads implementation? My only concern is that if SBCL on some platforms would have :sb-thread by default but not a reliable implementation, i.e. if SLIME suddenly starts using threads by default on platforms where it shouldn't.
I think (Dan reads this list, so he'll correct me if I'm wrong) that from 0.8.21 :sb-thread implies the previous combination of :sb-thread and :sb-futex before. That said, there is a possible snafu where an sbcl with :sb-thread will nevertheless refuse to start new threads if the underlying kernel is insufficiently futexed.
Doesn't that include, for example 2.4 kernels? Would this change imply that anyone grabbing a 0.8.21 SBCL and SLIME 1.2 on a 2.4 kernel would lose by default since SBCL would refuse to start new threads?
-Peter
-
Christophe Rhodes -
Helmut Eller -
Luke Gorrie -
Peter Seibel