[Bordeaux-threads-devel] Deprecating recursive locks
Antony
lisp.linux at gmail.com
Thu May 3 07:07:01 UTC 2012
On 5/2/2012 11:28 PM, Leslie P. Polzer wrote:
> Stelian Ionescu 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 think it's a bad idea. For me rapid prototyping is an important
> part of Lisp, and recursive locks support this approach. What
> Butenhof basically holds against them is that you're not looking
> at your threading code closely enough. But in the beginning stages
> of a project I actually might not want to do that. Doing away
> with them would be premature optimization. Add a note of caution
> to the docstring if you're that concerned, but don't remove them.
>
> Leslie
I had very similar thought. I think in general the problem is lots of
people try to write up software engineering rules based on the end
product (that is the code as it looks while being shipped). Whereas the
rules/guidelines should be done based on the process that gets you from
nothing to the end product. This is true no matter how rapid (or not)
the methodology is.
-Antony
More information about the bordeaux-threads-devel
mailing list