[Sbcl-help] Changes to the locking API, how to make this as painless as possible

[Nikodemus S. <nik...@ra...>]

So, my forthcoming changes to the locking API in SB-THREAD can be summarized as:

Both the (exported) MUTEX and the (unexported) SPINLOCK type and
functions and macros operating on those are replaced by a new LOCK
type, and operations on it.

Old APIs is still supported, as thin wrappers around LOCK and friends.

Now, the big question is, how to make it as painless as possible for
users to change over to the new API. The problem is with libraries:
either they would need to #-/+ like it's 1991, or their users would be
forced to update to a much newer SBCL.

While that has a certain appeal in getting the latest and greatest out
for as wide an audience as possible, it is also going to make a whole
bunch of people unhappy, I think.

So, my plan is to write an external library (not a contrib) called
SB-LOCK, which will do absolutely nothing on new SBCLs, but on those
without the LOCK API it will patch SB-THREAD to support it.

Then library implementors caring about people using old SBCLs can add
:depends-on (sb-lock) to their defsystems, or people using old SBCLs
with systems not doing that can patch their systems manually by
loading the SB-LOCK system.

I also plan to add :SB-LOCK feature to make it easy to detect the
presence of the new API without getting into #.#+ tricks.

How does this sound?

Cheers,

 -- Nikodemus