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

On Jun 8, 2015 10:04 PM, "Arthur A. Gleckler" 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. Okay, I know what to do now --basically

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

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 c

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

On Monday, June 8, 2015, Taylor R Campbell 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

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

On Monday, June 8, 2015, Taylor R Campbell wrote: >Saying "don't rely on it, it's not documented" in reference to an >essential service is basically saying "our system is an unfinished >toy, we're sorry you decided to use it". > > That is basically true of the thread system at least.

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

On Monday, June 8, 2015, Alexey Radul wrote: > 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 ste

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

Date: Mon, 8 Jun 2015 21:29:52 -0700 From: "Arthur A. Gleckler" On Monday, June 8, 2015, Taylor R Campbell wrote: > It sounds like you would be better served by having two locks: the web > server's data structure lock, and the logging lock. The logging lock > can be internal

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

Date: Mon, 8 Jun 2015 20:16:16 -0400 From: "Micah Brodsky" Saying "don't rely on it, it's not documented" in reference to an essential service is basically saying "our system is an unfinished toy, we're sorry you decided to use it". That is basically true of the thread system at l

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

On Monday, June 8, 2015, Taylor R Campbell wrote: > It sounds like you would be better served by having two locks: the web > server's data structure lock, and the logging lock. The logging lock > can be internal to the logging routines, and need not be exposed > elsewhere in the web server at a

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

On Tue, Jun 9, 2015 at 7:57 AM, Alexey Radul wrote: > > 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 ? I don't believe th

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

[TLDR: I think we can do better, and just because compatibility gets no respect as an engineering problem doesn't mean it doesn't deserve it. Also, boy it would be nice to have a package depot.] Hey, Alexey. Here's my take: People can be expected to rely on essential services (and even some ine

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

On Monday, June 8, 2015, Alexey Radul wrote: > 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

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

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 commu

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

Date: Mon, 8 Jun 2015 17:54:26 -0400 From: Micah Brodsky +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

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

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 gen

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

Date: Mon, 8 Jun 2015 13:40:35 -0700 From: "Arthur A. Gleckler" On Monday, June 8, 2015, Taylor R Campbell wrote: > 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

[MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Taylor R Campbell > wrote: > Hi, Arthur! I asked the list last year whether anyone relied on it: > > https://lists.gnu.org/archive/html/mit-scheme-devel/2014-11/msg5.html > > Nobody replied that they relied on it, and since the thread system is > undocumented I expec

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

Date: Sun, 7 Jun 2015 14:37:17 -0700 From: "Arthur A. Gleckler" 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