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

[Taylor R Campbell]

   Date: Mon, 8 Jun 2015 17:54:26 -0400
   From: Micah Brodsky <address@hidden>

   +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.

I can change it back on compatibility grounds.  I decided it was OK to
make the change because:

1. LOCK-THREAD-MUTEX already rejected recursive locks: any recursion
   was a weird quirk of WITH-THREAD-MUTEX-LOCKED.  The latter is not
   simply dynamic-wind of lock/unlock.

2. None of the thread system is documented, so anyone relying on any
   of it is not relying on very stable footing.

3. I expected that anyone who digs into internals and relies on them
   will be on the mit-scheme-devel mailing list.

4. I could not find any evidence of use of WITH-THREAD-MUTEX-LOCKED
   recursively.

5. At the time I found this, it was apparent that practically nobody
   had ever tried to use threads in anger because they would break if
   you looked at them funny.  (See, e.g.,
   <https://lists.gnu.org/archive/html/mit-scheme-devel/2012-04/msg00000.html>,
   which I fixed around the same time.  Other issues like that remain:
   I ran out of time to debug them.)

(This is certainly not the worst case of compatibility breakage that
MIT Scheme has seen!)