Re: [racket-users] managing competing access to filesystem within places

On Sat, Jun 22, 2019 at 9:45 PM Matthew Butterick wrote: > > > On 06 22 19, at 6:14 AM, Robby Findler wrote: > > One thing you can do, when the place-specific communication takes > multiple steps is to, like you did in the first example, put the > channels into a hash, but then on each iteration

Re: [racket-users] managing competing access to filesystem within places

> On 06 22 19, at 6:14 AM, Robby Findler wrote: > > One thing you can do, when the place-specific communication takes > multiple steps is to, like you did in the first example, put the > channels into a hash, but then on each iteration of the loop, pull all > of them out and put them into a gia

Re: [racket-users] managing competing access to filesystem within places

Thanks! One thing you can do, when the place-specific communication takes multiple steps is to, like you did in the first example, put the channels into a hash, but then on each iteration of the loop, pull all of them out and put them into a giant select that takes the relevant step forward for th

Re: [racket-users] managing competing access to filesystem within places

> On 06 15 19, at 8:31 AM, Robby Findler wrote: > > A standard way to work with this is to send a channel over in the > first communication and then the communication that's specific to that > initial request happens on that channel. The precise way you set this > up depends on what invariants

Re: [racket-users] managing competing access to filesystem within places

> On Jun 15, 2019, at 8:31 AM, Robby Findler wrote: > > A standard way to work with this is to send a channel over in the > first communication and then the communication that's specific to that > initial request happens on that channel. This is probably the crudest possible implementation of

Re: [racket-users] managing competing access to filesystem within places

I guess one way to look at it is that place-channels have guarantees that are like [1] when putting and guarantees that are like regular channels when getting. Or, put another way, you can't sync on sending with place-channels, only on receiving. So it is a similar idea, yes. I'm not sure exactly w

Re: [racket-users] managing competing access to filesystem within places

> On Jun 15, 2019, at 8:31 AM, Robby Findler wrote: > > Place channels are asynchronous, not syncronous (i.e. you don't have > two-way rendez-vous). So the call to put returns immediately in > `loopback-p` before the other end receives the result. And now the > next iteration of the loop's get

Re: [racket-users] managing competing access to filesystem within places

Place channels are asynchronous, not syncronous (i.e. you don't have two-way rendez-vous). So the call to put returns immediately in `loopback-p` before the other end receives the result. And now the next iteration of the loop's get is in parallel to the put from the previous iteration's. A standa

Re: [racket-users] managing competing access to filesystem within places

> On Jun 14, 2019, at 8:15 PM, Matthew Butterick wrote: > > But even after approving a lock request from a certain rendering place, the > lock server would end up with repeat lock requests from there. BTW here's a minimal example showing the puzzling message-garbling behavior between places.

Re: [racket-users] managing competing access to filesystem within places

> On Jun 14, 2019, at 4:34 PM, Matthew Flatt wrote: > > Sometimes, staying out of the error-triggering space is unavoidable, > and the possible errors are well enough defined by all filesystems, so > retrying is a workable solution. If you really have to be in that > space, then retry an arbitr

Re: [racket-users] managing competing access to filesystem within places

At Fri, 14 Jun 2019 15:26:17 -0700, Matthew Butterick wrote: > > > > On Jun 13, 2019, at 6:43 PM, Matthew Flatt wrote: > > > > > > Oh, don't do that. Unreliable workarounds to concurrency problems > > really do come back to bite you later. > > To ask the second dumbest possible question, what

Re: [racket-users] managing competing access to filesystem within places

> On Jun 13, 2019, at 6:43 PM, Matthew Flatt wrote: > > > Oh, don't do that. Unreliable workarounds to concurrency problems > really do come back to bite you later. To ask the second dumbest possible question, what error-recovery policies are reliable under concurrency? (Put another way, wh

Re: [racket-users] managing competing access to filesystem within places

On 6/13/2019 9:16 PM, Matthew Butterick wrote: On Jun 13, 2019, at 10:04 AM, Matthew Flatt > wrote: I recommend a lock-serving place in Pollen to manage concurrency for parallel rendering. Don't let multiple places try to read and/or write to the same file, and don't

Re: [racket-users] managing competing access to filesystem within places

At Thu, 13 Jun 2019 18:16:50 -0700, Matthew Butterick wrote: > > > On Jun 13, 2019, at 10:04 AM, Matthew Flatt wrote: > > > > I recommend a lock-serving place in Pollen to manage concurrency for > > parallel rendering. Don't let multiple places try to read and/or write > > to the same file, and

Re: [racket-users] managing competing access to filesystem within places

> On Jun 13, 2019, at 10:04 AM, Matthew Flatt wrote: > > I recommend a lock-serving place in Pollen to manage concurrency for > parallel rendering. Don't let multiple places try to read and/or write > to the same file, and don't try to use filesystem locks. Thanks for the suggestion. I see wha

Re: [racket-users] managing competing access to filesystem within places

I recommend a lock-serving place in Pollen to manage concurrency for parallel rendering. Don't let multiple places try to read and/or write to the same file, and don't try to use filesystem locks. You can use filesystem locks to manage concurrency, but it's not convenient. Part of the problem is t

[racket-users] managing competing access to filesystem within places

To Pollen, I've recently added a parallel-rendering facility with places, in emulation of how Racket docs are rendered in parallel. But it doesn't quite work — I get intermittent / inconsistent errors from the filesystem (for instance, certain files that should exist do not, or certain files th