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 Marc Nieper-Wißkirchen 03 Aug 2020 12:12 UTC

Am Mo., 3. Aug. 2020 um 10:04 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> 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.

My point is that if the current working directory (per process of per
thread) can currently only be changed for single-threaded programs,
SRFI 170 should provide some mechanism for multi-threaded programs as
well. I don't mind if it is at a higher abstraction (at the thread
level, for example) than in POSIX (although it is probably easier to
first provide the raw C interface first and then some sophisticated
abstraction on top of it).