Re: Per-process vs per-thread current-directory once more Lassi Kortela 03 Aug 2020 12:20 UTC
> 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). Sorry, I misunderstood what you were after. Implementing `current-directory` as a parameter is a proven way to do what you suggest for multi-threaded programs. I anticipate that if we give both a low-level procedure and a high-level procedure in the same SRFI, it can give the impression that we encourage the low-level one to be used as an equally good alternative to the high-level one, whereas it would be better to discourage people from reaching for low-level procedures for general usage. Lots of programmers, even good ones, have the instinct to "optimize" things that would be better left unoptimized. If decidedly low-level stuff goes into distinct low-level SRFIs that are clearly advertised as such, that puts up a slightly stronger mental barrier and lets people know what they are getting into.