[Bordeaux-threads-devel] Deprecating recursive locks

Stelian Ionescu sionescu at cddr.org
Wed May 2 15:27:51 UTC 2012


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

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120502/27bf32fe/attachment.sig>


More information about the bordeaux-threads-devel mailing list