[Bordeaux-threads-devel] Deprecating recursive locks
James M. Lawrence
llmjjmll at gmail.com
Wed May 2 15:15:21 UTC 2012
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.
More information about the bordeaux-threads-devel
mailing list