Micah, Respectfully, in general, users who rely on subtleties of the detailed semantics of undocumented procedures [*] should expect occasional incompatible changes. And what communication channel do we have except postings on the devel mailing list?
As to ecosystem stewardship, do we as a community have the need and resources to maintain a package repository, such as hackage.haskell.org, planet.racket-lang.org, or even interoperate with snow.iro.umontreal.ca ? That seems a more basic step than permitting fear of potential unknown users' potential unknown uses of system internals for nefarious purposes [+] to impede progress. Best, ~Alexey [*] It is regrettable that the thread subsystem happens to consist entirely (as far as I can tell) of undocumented procedures. [+] Such as spawning threads only to lock them up reentrantly On Mon, Jun 8, 2015 at 5:54 PM, Micah Brodsky <micah...@csail.mit.edu> wrote: > 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 _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
