Nikodemus Siivola <nikodemus@...> writes:
> On 21 September 2011 18:53, Anton Kovalenko <anton@...> wrote:
>> Don't deprecate old API at all.
> I mislike this for following reasons:
[... a good reason elided...]
> * Not deprecating the old stuff in favor of the new makes the "what
> should I use?" unclear.
What is unclear to me is whether answering this question is an
implementor's job at all. To be precise, answering it in the _manual_ is
ok -- that's what manuals are for. Answering it by breaking old code may
communicate "I should use some other Lisp" instead of your intent.
I have no objections at all to "moral deprecation" that doesn't break
any code, of course.
> That said, I'm happy to phase it out /slowly/.
Like, document it as deprecated and watch what will users do for 15
years? Lisp is slow when it comes to bit rot; do we want SBCL to be a
fastest implementation in _this_ respect?
As of maintenance headache:
Having (not (eql #\0 (char (lisp-implementation-version) 0))) has some
implications, and it's just one of them. Also, there are two kinds of
maintenance headache: one that saves /users/ from porting headache, and
another that is completely self-inflicted (like ldso_stubs). I think
it's very important to start headache treatment with the latter.
> Also, something like an SB-LEGACY contrib is also possible, which
> could provide support for legacy APIs in the long term without
> cluttering up the main build -- and would also make their status
I like this idea. Also, it would be great to have SB-LEGACY in place for
some time /before/ deprecation warning: for smooth API transitions it's
crucial to provide a "future-proof" way of writing code.
> The non-futex implementation will not stay there. It is just way too
> Fairness is an irrelevant sidenote here, really. I'm thinking about
> adding a &KEY FAIR to MAKE-LOCK to cater to those cases.
Sorry for uneducated guess. I discovered recently that your plans were
discussed on IRC extensively, and I've missed all those discussions
entirely. It's much more clear for me now.
While I doubt that anyone will miss /lutexes/, the signal safety issue
deserves some separate attention. Are problems caused by async signal
handlers /using/ lutexes?
Also, it seems that running Lisp code in async signal handlers is
inherently unsafe. Migration to safepoints on POSIX systems seems to
make this problem solvable, however (and whenever it's solved,
lutexes might become safe enough -- if only they are still there :).
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia