Re: Per-thread working directory and umask proposal Lassi Kortela 24 Apr 2020 11:37 UTC

>   You mean Scheme `spawn` would be implemented in something like this?
>
>     fork()
>     if child {
>        chdir()
>        exec()
>     }
>
> You're right, Gauche's sys-fork-and-exec actually does this.
> I was thinking to expose posix_spawn() in the generic Scheme process API.
> Considering it again, you don't want to call chdir() while other threads
> are running (which may call non-Scheme library),
> so mandating fork-chdir-exec is maybe a good thing.

Yes - that's exactly what I had in mind, for the reasons you state.

> Other scenarios that you want explicitly set process working directory is:
> - a daemon process that chdir() to designated working directory.

The proposals so far imply that new threads inherit the working
directory of the thread that spawned them. if you set the
working-directory parameter at the start of the program before creating
the other threads, they all inherit the wd of the main thread.

It is harder to change the global wd later if it's just a parameter. But
changing the process-global wd later may mess up other threads' ideas of
the wd; those threads would then produce invalid pathnames from invalid
assumptions.

> - a shell-like program whose working directory is on the device you want
> to umount, so you want to tell it to chdir() elsewhere.

Here the OS may prevent the unmount if the process wd is on the mounted
device, so you're definitely right.