On Wed, May 2, 2012 at 11:27 AM, Stelian Ionescu <sionescu@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@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.