Review of SRFI 170 through 3.2 I/O hga@xxxxxx (22 Apr 2020 17:13 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (22 Apr 2020 20:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 20:53 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (22 Apr 2020 21:29 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 21:36 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 21:43 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (23 Apr 2020 03:38 UTC)
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx (22 Apr 2020 23:58 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 07:02 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 07:05 UTC)
Re: Review of SRFI 170 through 3.2 I/O Göran Weinholt (23 Apr 2020 10:54 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley (23 Apr 2020 11:09 UTC)
Per-thread umask Lassi Kortela (23 Apr 2020 11:30 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 11:44 UTC)
Re: Per-thread umask Lassi Kortela (23 Apr 2020 11:47 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 11:59 UTC)
Re: Per-thread umask John Cowan (23 Apr 2020 15:03 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 15:20 UTC)
Re: Per-thread umask Lassi Kortela (23 Apr 2020 16:02 UTC)
Re: Per-thread umask John Cowan (23 Apr 2020 16:03 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 11:14 UTC)
current directory and openat() et al Lassi Kortela (23 Apr 2020 11:27 UTC)
Re: current directory and openat() et al Marc Feeley (23 Apr 2020 13:56 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley (23 Apr 2020 11:33 UTC)
Normalizing the current directory Lassi Kortela (23 Apr 2020 11:39 UTC)
Re: Normalizing the current directory Marc Feeley (23 Apr 2020 11:55 UTC)
Re: Normalizing the current directory Lassi Kortela (23 Apr 2020 12:10 UTC)
Per-thread working directory and umask proposal John Cowan (23 Apr 2020 14:13 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 14:16 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 16:07 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 16:14 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 16:25 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 17:26 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 17:55 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 18:55 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 20:12 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (23 Apr 2020 22:17 UTC)
Re: Per-thread working directory and umask proposal Lassi Kortela (24 Apr 2020 08:43 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (24 Apr 2020 11:27 UTC)
Re: Per-thread working directory and umask proposal Lassi Kortela (24 Apr 2020 11:37 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (24 Apr 2020 12:22 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (24 Apr 2020 12:28 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (26 Apr 2020 09:19 UTC)
Re: Per-thread working directory and umask proposal John Cowan (27 Apr 2020 22:46 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (27 Apr 2020 23:42 UTC)
Re: Per-thread working directory and umask proposal John Cowan (28 Apr 2020 00:42 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (28 Apr 2020 00:56 UTC)
os-working-directory Lassi Kortela (29 Apr 2020 09:23 UTC)
Re: os-working-directory Duy Nguyen (29 Apr 2020 09:28 UTC)
current-umask Lassi Kortela (29 Apr 2020 09:43 UTC)
Windows Lassi Kortela (29 Apr 2020 09:47 UTC)
Re: Windows Lassi Kortela (29 Apr 2020 09:49 UTC)
Re: Windows John Cowan (29 Apr 2020 14:53 UTC)
Re: current-umask hga@xxxxxx (29 Apr 2020 13:14 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 13:25 UTC)
Re: current-umask Marc Feeley (29 Apr 2020 13:31 UTC)
Re: current-umask Marc Feeley (29 Apr 2020 13:45 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 14:12 UTC)
Re: current-umask hga@xxxxxx (29 Apr 2020 16:21 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 16:44 UTC)
Re: current-umask John Cowan (30 Apr 2020 04:02 UTC)
Re: os-working-directory John Cowan (30 Apr 2020 02:49 UTC)
Re: os-working-directory Lassi Kortela (30 Apr 2020 06:12 UTC)
Re: os-working-directory Sebastien Marie (30 Apr 2020 07:19 UTC)
Re: os-working-directory Sebastien Marie (30 Apr 2020 07:53 UTC)
Should the SRFI mandate current-directory per thread? Lassi Kortela (30 Apr 2020 12:14 UTC)
Re: Should the SRFI mandate current-directory per thread? Sebastien Marie (30 Apr 2020 17:00 UTC)
Re: Per-thread working directory and umask proposal hga@xxxxxx (28 Apr 2020 01:03 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (28 Apr 2020 01:42 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (30 Apr 2020 07:11 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (30 Apr 2020 11:33 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 18:38 UTC)
Re: Review of SRFI 170 through 3.2 I/O Sebastien Marie (23 Apr 2020 13:32 UTC)
Definition of working directory Lassi Kortela (23 Apr 2020 13:51 UTC)
Re: Definition of working directory Marc Feeley (23 Apr 2020 14:07 UTC)
Re: Definition of working directory Sebastien Marie (23 Apr 2020 15:31 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Nieper-Wißkirchen (23 Apr 2020 15:24 UTC)
Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 15:38 UTC)
Re: Separate high-level and low-level APIs Marc Nieper-Wißkirchen (23 Apr 2020 15:44 UTC)
Re: Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 15:48 UTC)
Re: Separate high-level and low-level APIs hga@xxxxxx (23 Apr 2020 16:19 UTC)
Re: Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 16:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx (23 Apr 2020 15:41 UTC)

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.