Date: Sun, 7 Jun 2015 14:37:17 -0700 From: "Arthur A. Gleckler" <sch...@speechcode.com>
I'm just upgrading to MIT Scheme 9.2, and my code is breaking in several places because of your change to Remove support for recursion in WITH-THREAD-MUTEX-LOCKED <http://git.savannah.gnu.org/cgit/mit-scheme.git/commit/?id=d7241d6fe8b151f6d15db9cac8fba44b074ca215>. Can you tell me why you made that change? I can't see a correctness or performance advantage, and the change list comment gives no justification. Not supporting recursion is a nuisance in cases where one has utility procedures that may or may not be run in a context where the lock is already held. Hi, Arthur! I asked the list last year whether anyone relied on it: https://lists.gnu.org/archive/html/mit-scheme-devel/2014-11/msg00005.html Nobody replied that they relied on it, and since the thread system is undocumented I expected its use outside the tree to be limited. The reason I decided to do this is that it is practically always a mistake to rely on recursion: for each mutex, you should know whether or not you hold it at each point when you need access to the resource it protects, and you should know what other locks are held in order to determine a consistent lock order. Utility routines whose callers might or might not hold the lock are suspect and tend to suggest insufficiently considered design: What is the invariant the lock provides? If the caller doesn't need to hold the lock, why does the lock need to be there at all? There are legitimate cases where recursive locks make sense, but most uses are best served by a nonrecursive lock abstraction. You can always build a recursive lock out of a nonrecursive lock and a condition variable. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
