|
From: | Micah Brodsky |
Subject: | Re: [MIT-Scheme-devel] non-recursive mutexes |
Date: | Tue, 9 Jun 2015 01:29:20 -0400 |
IMO, you’re both right. With a simple monitor architecture, recursive re-entry is as legitimate as having exposed APIs that are also useful internally as building blocks for more complex transactions. Simple solutions for simple problems. In a more complex architecture, you want to keep closer control over what’s held when and crash proactively if your presumptions are violated e.g. by re-entry. Taylor’s latest patch lets the dev choose, which is how it should be! (Mind, locks are still horrible, horrible things. The first thing I usually do is write a better set of abstractions suited to the problem at hand. …maybe I should package some of those. ;) --Micah From: address@hidden [mailto:address@hidden On Behalf Of Arthur A. Gleckler On Monday, June 8, 2015, Taylor R Campbell <address@hidden> wrote:
Still, when logging is used in the web server, the lock needs to reside somewhere. It shouldn't have to be passed around separately from the web server, so I just incorporated it into the web server.
Interesting. I'm not sure what interactions might happen at the Scheme level, though. |
[Prev in Thread] | Current Thread | [Next in Thread] |