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.