Date: Mon, 8 Jun 2015 17:54:26 -0400 From: Micah Brodsky <micah...@csail.mit.edu>
+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!) _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
