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

[Faré <fa...@gm...>]

On Fri, Sep 23, 2011 at 07:46, Nikodemus Siivola
<nik...@ra...> wrote:
> On 21 September 2011 18:53, Anton Kovalenko <an...@sw...> wrote:
>
>> Don't deprecate old API at all.
>
> I mislike this for following reasons:
>
> * We still at least bits and pieces of the new API: the old cannot be
> just extended. Eg. WITH-MUTEX and WITH-RECURSIVE-LOCK need a WITH-LOCK
> replacement that works with recursivity being a property of the lock
> and not the locking site.
>
For a compatibility layer, there could be two actual different lock types,
and a "not yet determined" type that would "lock" into one of the former
at the first use. Of course, to avoid a race condition at said first use,
that "locking" would require holding a/the non-recursive lock. Ouch.
Ugly, but that's a valid compatibility layer.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org