Per-process vs per-thread current-directory once more Lassi Kortela (02 Aug 2020 19:36 UTC)
Re: Per-process vs per-thread current-directory once more Marc Nieper-Wißkirchen (03 Aug 2020 07:30 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:04 UTC)
Re: Per-process vs per-thread current-directory once more Marc Nieper-Wißkirchen (03 Aug 2020 12:12 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 12:20 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:08 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:17 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:25 UTC)

Re: Per-process vs per-thread current-directory once more Lassi Kortela 03 Aug 2020 08:04 UTC

>> I still think it would be clearer to use a per-thread CWD in Scheme
>> implementations where that is the custom. If current-directory is a

> So what does is mean for multithreaded programs? That they cannot even
> set the current directory per process?
>
> They should at least be able to do what a C program can do.

In implementations with a per-thread current-directory, it is a
parameter object. Hence each thread can change its own working directory
by binding the parameter to a different value.

Changing the OS working directory in those implementations is mainly
useful when dealing with FFI. You can also use the FFI to make calls to
chdir() and friends.

It's one of the major benefits of a high-level language Scheme that
programs cannot do everything a C program can do without resorting to
FFI or "unsafe" procedures. It lets us reason more easily about many
more things, and the implementation can lean on those restrictions to
provide more convenience to the programmer.