On Thu, Apr 23, 2020 at 10:02:16AM +0300, Lassi Kortela wrote:
> >     Could we simply add some prose to SRFI 170 permitting
> >     implementations to
> >     translate relative pathnames per the thread CWD before passing them to
> >     the syscalls?
> >
> > It seems to me that would break portability, but I can't quite put my
> > finger on why.
>
> 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. 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.

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

/Göran