On Thu, Apr 23, 2020 at 12:53:47PM +0200, Göran Weinholt wrote:
> 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).

I am a bit shared. I understand that having proper "current working directory"
based on parameter-like semantic, and having it per thread could be a good
thing. But SRFI 170 is about "POSIX API", and I would expect the standard
behaviour found in C world, where getcwd() is a per-process property (but I
didn't found formal definition of cwd as process property in Posix definition).

At minima, the direct reference about getcwd() and chdir() should be avoided,
and the difference with them properly documented.

The same reasoning could be done about umask (but here, Posix is explicitly
saying that it is a property of the process).

Thanks.
--
Sebastien Marie