This discussion reminds me that the umask should also be handled similarly (i.e. be thread specific).  Gambit doesn’t yet have any procedures to affect the umask, but this will be implemented using a parameter object similarly to current-directory for the same reasons (you wouldn’t generally want a thread to change the umask globally, as this would interfere with the permission of files created by other threads).

Marc

> On Apr 23, 2020, at 6:53 AM, Göran Weinholt <xxxxxx@weinholt.se> 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).
>
> /Göran
>