Well it depends…

With green threads the binding of the current directory parameter can be copied to the process’ cwd on calls to C funtions (that care about the cwd).  This could be done automatically by the FFI, possibly with some hints from the programmer.  Many Schemes only have green threads.

Implementation is harder with truly parallel threads because the process has a single cwd.  It could be part of the spec that (current-directory string) only sets the process’ cwd when not in the scope of a parameterize, otherwise it simply sets the latest binding.  So this API (using parameter objects) can express the same cwd mutations as the proposed (set-current-directory! string), but has the advantage of allowing dynamic binding for procedures such as open-input-file that need to resolve relative file names.

In any case, in a truly parallel setting, some synchronization is required around the mutation of the process’ cwd whether (current-directory string) or (set-current-directory! string) is used.

Marc

> On Jul 21, 2019, at 8:40 AM, Duy Nguyen <xxxxxx@gmail.com> wrote:
>
> On Sun, Jul 21, 2019 at 7:27 PM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:
>>
>> How about a “current-directory” parameter object with
>>
>> (current-directory) => string
>> (current-directory string)   ;; sets the current directory
>>
>> just like current-output-port, current-exception-handler, etc
>
> Gauche has this, except that it's not a parameter. Its manual also
> mentions "this function is in ChezScheme, MzScheme and some other
> Scheme implementations"
>
>>
>> This has the advantage that each thread can manage their own current directory using “parameterize” to avoid interfeering with other threads
>
> cwd is a global property anyway if I remember correctly, simply
> parameterizing it won't help multi threads.
> --
> Duy
>