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
John Cowan
(02 Aug 2020 20:44 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.