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
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
bordeaux-threads-devel@common-lisp.net
-
Antony -
Leslie P. Polzer