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@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