Re: Per-thread working directory and umask proposal Marc Nieper-WiÃkirchen 23 Apr 2020 17:26 UTC
Am Do., 23. Apr. 2020 um 18:25 Uhr schrieb Marc Feeley <email@example.com>: [...] > > b) get a per-thread CWD that is a copy of foo's per-thread CWD, or > > > > c) get a per-thread CWD that *is* foo's per-thread CWD, such that mutations done in foo are visible in bar and vice versa? > > c of course… :-) Copying the parameter (option b) would introduce a restriction (not being able to mutate) that is an arbitrary choice by the spec designer. If the programmer wants a copy they can add a (parameterize ((current-directory (current-directory))) …) around their code. I think it is a bad design in general to do something automatically that can’t be undone. Also, if you argue that copying parameters is “the right thing” you may introduce performance issues when the dynamic environment contains lots of bindings. I would argue instead that option (b) is the more general. If you want mutability across threads, just put the value in a box and don't modify the parameter directly but just what's in the box. With (c), on the other hand, you cannot get true thread local parameters, can you? The reparameterization trick you mention does not work if the code spawning the thread does not know about all thread-local parameters. With respect to the performance issues, I have no simple answer yet. It would suffice to spawn parameters on demand, which would just make the mutation more costly, I think. In any case, I would want that an implementation such that the body of a parameterize form is in tail position with respect to the whole form (which should really have become part of the standard) is easily doable (see also my SRFI 157 and what Racket does).