Hi, Taylor. +1 for Arthur on this. I don't know whether my RPC library relies anywhere on recursive locking, but I'm not currently maintaining it and I'd really rather not have the most difficult parts of it (i.e. thread management) rot out from under me while I'm busy with other projects.
In general, deciding whether to make breaking changes based on whether or not there is a reply to one or two postings on an obscure mailing list is a lousy strategy for software ecosystem stewardship. Speaking as an alum of MS's application compatibility group, if you don't want your users hating your guts, the default assumption needs to be that breaking changes are unacceptable until proven otherwise. "Encouraging good coding practice" is hardly justification to wing it. --Micah -----Original Message----- From: mit-scheme-devel-bounces+micahbro=csail.mit....@gnu.org [mailto:mit-scheme-devel-bounces+micahbro=csail.mit....@gnu.org] On Behalf Of Taylor R Campbell Sent: Monday, June 08, 2015 3:02 PM To: Arthur A. Gleckler Cc: MIT Scheme Developers Subject: Re: [MIT-Scheme-devel] non-recursive mutexes 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=d7241d6fe8b151f6 d15db9cac8fba44b074ca215>. 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 _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
