> On Apr 23, 2020, at 7:30 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>> 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).
>
> Would the implementation be something like this:
>
> with_global_lock_held {
>    mode_t old_global_mask = umask(current_thread_mask);
>    some_syscall();
>    umask(old_global_mask);
> }
>

For Gambit that would not be the gist of the implementation.  The implementation of the umask would model the implementation of current-directory, that is both would be parameter objects and they would “feed” the underlying open(), etc system calls with the value they are bound to.

In other words current-directory and (in a future release) current-umask are abstractions of the POSIX chdir() and umask() syscalls but they don’t actually call those syscalls (because the semantics of those syscalls in a threaded world is broken).

Marc