On Thu, Apr 23, 2020 at 04:51:33PM +0300, Lassi Kortela wrote:
> > I am a bit shared. I understand that having proper "current working directory"
> > based on parameter-like semantic, and having it per thread could be a good
> > thing. But SRFI 170 is about "POSIX API", and I would expect the standard
> > behaviour found in C world, where getcwd() is a per-process property
>
> Simplicity is a good argument for a per-process CWD. However, some major
> Scheme implementations already have a per-thread CWD that is used by the
> RnRS procedures (among others) for interpreting pathnames. Having different
> interpretation rules for the SRFI 170 procedures would probably be confusing
> to users.
>
> Would you consider it an acceptable compromise if the per-thread CWD can be
> disabled via (parameterize ((working-directory #f)) ...) or similar?

I don't think adding such construction would be valuable. My point was mostly
about taking care of properly document the behaviour, specially if it isn't the
"standard" behaviour.

But I like the proposal of John Cowan:

> 1) SRFI 170 `working-directory` and `umask` are per-thread if and only if
> the other R7RS procedures that accept pathnames are implemented using
> per-thread versions in a particular Scheme implementation providing SRFI
> 170.

Having consistent behaviour with others procedures makes sense to me.

> > (but I didn't found formal definition of cwd as process property in Posix definition).
>
> It's here: <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_447>

thanks !

--
Sebastien Marie