[Bordeaux-threads-devel] Deprecating recursive locks

[James M. Lawrence]

On Wed, May 2, 2012 at 11:27 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> On Wed, 2012-05-02 at 11:15 -0400, James M. Lawrence wrote:
>> On Tue, Apr 17, 2012 at 11:21 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
>> > They're an ugly hack, as described their inventor David Butenhof
>> > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
>> > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
>> > lock, but it's not a posix recursive lock), so I was thinking of making
>> > a 1.0 release in which to remove them altogether.
>> >
>> > What do you think ?
>>
>> I currently use a recursive lock for debug logging. In the past I
>> wrapped *debugger-hook* with a recursive lock in order to avoid
>> multiple simultaneous debugger popups. Both are cases of throwaway
>> code.
>>
>> David Butenhof does mention that recursive locks "can be a great tool"
>> as long as they are properly understood as a temporary measure. That's
>> how I use them, and others may as well. Yes, they are a hack, but they
>> are a convenient hack.
>>
>> If recursive locks are removed then I would expect people to write
>> their own half-ass implementations, as I would do for my debug logger.
>> I agree that using them in a non-temporary context may constitute poor
>> design, however that does not imply that they should be removed.
>>
>> Perhaps adding a note to the documentation regarding the hackiness of
>> recursive locks (and/or even linking to the Butenhof post) would
>> suffice in lieu of outright deletion?
>>
>> If you do decide to remove them, consider issuing deprecation warnings
>> in the next release (or longer) before the actual removal. There is at
>> least one logging library in quicklisp which uses a recursive lock. I
>> assume other projects out there would be broken as well.
>
> Which one ? Such library is broken because few CL implementations
> actually have recursive locks

log4cl, released a few months ago.

You mentioned that Clozure does not support recursive locks. The funny
thing about Clozure is that ccl:make-lock actually returns a recursive
lock. So bt:make-recursive-lock is, through coincidence, providing a
recursive lock by calling ccl:make-lock.

Thus users may be fooled into thinking bordeaux-threads is making some
guarantee when it hasn't. The behavior of Clozure may change in the
future, for all we know.

The best of both worlds is to move recursive locks to the
introspection/debugging section of the documentation. Recursive locks
would be there as convenience for the use case I mentioned, while
users would be made aware that they are not dependable across
implementations.