Re: Per-thread working directory and umask proposal Marc Feeley 23 Apr 2020 16:25 UTC

> On Apr 23, 2020, at 12:07 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
>
>
> On Thu, Apr 23, 2020 at 10:16 AM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:
>
> I understand that SRFI 170 is about the POSIX API where chdir(), and also umask(), have a well defined behaviour.
>
> That 's true.  But on reflection I think it is better to break Posix slightly than to make SRFI 170 and other R7RS procedures inconsistent in their interpretation of relative pathnames.
>
> Some questions about per-thread implementation:
>
> 1) Do you think that systems that expose green threads rather than kernel threads might reasonably provide the per-thread interpretation anyway?  The implementation schema you have been discussing seems to fit that interpretation.

I’m not sure I understand your question.  Gambit uses green threads, with thread-specific current-directory, and the implementation does not interfere with the process CWD.

>
> 2) When thread foo spawns thread bar, does bar:
>
> a) get a per-thread CWD that is a copy of the per-process CWD, or
>
> 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.

>
> These are the three implementations documented for SRFI 39 parameters.  In R7RS-small, parameter mutations are not standardized (though not disallowed either), so the difference between (b) and (c) is not visible.
>
> In any case I agree with Lassi: consistency between SRFI 170 and the rest of R7RS-large is more important than exact consistency with Posix.

Then we have a problem because I think the two semantics are incompatible.  You can’t have chdir() and eat your Scheme high-level semantics too (as soon as you have threads, whether they are threads built into the Scheme implementation or implemented in a Scheme thread library using call/cc or something similar).

Marc