Re: [MIT-Scheme-devel] non-recursive mutexes

[Alexey Radul]

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