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: mit-scheme-devel-bounces+micahbro=csail.mit....@gnu.org [mailto:mit-scheme-devel-bounces+micahbro=csail.mit....@gnu.org] On Behalf Of Arthur A. Gleckler Sent: Tuesday, June 09, 2015 1:05 AM To: Taylor R Campbell Cc: mit-scheme-devel@gnu.org Subject: Re: [MIT-Scheme-devel] non-recursive mutexes On Monday, June 8, 2015, Taylor R Campbell <campb...@mumble.net> wrote: The log file is specific to the particular web server instance, so the lock that controls the log file belongs in the web server data structure. Having two locks opens the possibility of ordering problems. Having just one eliminates that issue. Only if your logging routines need to get at the rest of the web server data structures. If your logging routines are self-contained, the lock ordering issue is trivial and needn't even be mentioned -- you could factor logging out into another library, like C stdio. 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. (C stdio streams have locks too -- but you don't usually notice, even if you call printf while you hold some pthread_mutex, because you ~never have to write code that runs with the stdio stream locked.) Interesting. I'm not sure what interactions might happen at the Scheme level, though.
_______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
