[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] non-recursive mutexes
From: |
Alexey Radul |
Subject: |
Re: [MIT-Scheme-devel] non-recursive mutexes |
Date: |
Mon, 8 Jun 2015 18:57:12 -0400 |
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 <address@hidden> 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: address@hidden
> [mailto:address@hidden 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" <address@hidden>
>
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>
>
> _______________________________________________
> MIT-Scheme-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
- Re: [MIT-Scheme-devel] non-recursive mutexes, (continued)
- Re: [MIT-Scheme-devel] non-recursive mutexes, Arthur A. Gleckler, 2015/06/09
- Re: [MIT-Scheme-devel] non-recursive mutexes, Arthur A. Gleckler, 2015/06/15
- Re: [MIT-Scheme-devel] non-recursive mutexes, Markus:, 2015/06/09
- Re: [MIT-Scheme-devel] non-recursive mutexes, Markus:, 2015/06/09
- Re: [MIT-Scheme-devel] non-recursive mutexes, Markus:, 2015/06/09
Re: [MIT-Scheme-devel] non-recursive mutexes, Micah Brodsky, 2015/06/08
- Re: [MIT-Scheme-devel] non-recursive mutexes, Taylor R Campbell, 2015/06/08
- Re: [MIT-Scheme-devel] non-recursive mutexes,
Alexey Radul <=
- Re: [MIT-Scheme-devel] non-recursive mutexes, Arthur A. Gleckler, 2015/06/08
- Re: [MIT-Scheme-devel] non-recursive mutexes, Micah Brodsky, 2015/06/08
- Re: [MIT-Scheme-devel] non-recursive mutexes, Taylor R Campbell, 2015/06/09
- Re: [MIT-Scheme-devel] non-recursive mutexes, Arthur A. Gleckler, 2015/06/09
Re: [MIT-Scheme-devel] non-recursive mutexes, Alex Shinn, 2015/06/08
Re: [MIT-Scheme-devel] non-recursive mutexes, Arthur A. Gleckler, 2015/06/09