Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 23 Apr 2020 11:14 UTC
>> The kernel translates relative pathnames to absolute ones anyway. It >> shouldn't be a problem if we translate one step earlier, on the Scheme side. > > I'd like if it were possible to keep a current working directory per > thread, fiber or whatever. That's the exact purpose of this proposal :) Gambit and Kawa would like it as well. > Are you aware of the *at() syscalls? From the Linux openat(2) manpage: > > Second, openat() allows the implementation of a per-thread > "current working directory", via file descriptor(s) maintained > by the application. (This functionality can also be obtained > by tricks based on the use of /proc/self/fd/dirfd, but less > efficiently.) > > These types of syscalls are also in POSIX-1.2008, AFAICT. Yes. The latest edition of POSIX has these ones: faccessat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/faccessat.html fchmodat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/fchmodat.html fchownat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/fchownat.html fstatat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/fstatat.html linkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/linkat.html mkdirat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdirat.html mkfifoat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkfifoat.html mknodat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/mknodat.html openat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/openat.html readlinkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/readlinkat.html renameat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/renameat.html symlinkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/symlinkat.html unlinkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/unlinkat.html utimensat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/utimensat.html (excerpted from <https://github.com/lassik/emacs-posix-manual/blob/master/posix-manual-data.el>) > I suspect that if the current working directory is specified in terms > of parameter-like semantics then it should be possible to make use of > openat() etc behind the scenes Gambit does some of this; I suggest grepping the source code > while implementors who can't use such > syscalls can still have a current working directory parameter that is > more or less just a string (plus a check to see that the new directory > exists, I guess). AFAICT it should work as you say. OS kernels checks for existence of pathnames, so it's probably more reliable to defer existence checks to them and do only syntactic manipulation (merging the pathnames) on the Scheme side. Or did you mean specifically that setting the `working-directory` parameter should cause an error in case the directory does not exist, thereby matching the behavior of the chdir() syscall? That's a clever point that didn't occur to me. I guess it could use access() to check it, which is quite fast.