> 1) Controlling the posix working directory and umask (that apply to the OS process) > 2) The mapping of these concepts to Scheme threads > > So for the first there could be the procedures > > (posix-current-directory [ <dir> ]) that calls getcwd() or chdir() > (posix-current-file-permission-mask [ <mask> ]) that calls umask() > > And for the second there could be the SRFI 39 parameters > > (current-directory [ <dir> ]) that reads or assigns the parameter > (current-file-permission-mask [ <mask> ]) that reads or assigns the parameter I like the symmetry. Perhaps `posix-` should be `os-` since the current directory works using Windows API as well and there's nothing intrinsically POSIX specific about it. For the umask, there's a stronger case for `posix-`. If `current-file-permission-mask` is designed with the option of being portable to non-Unix platforms, then `<mask>` should probably be an opaque object instead of an integer. That may be too fancy... perhaps we should simply specify that it has OS-dependent meaning, and on POSIX systems, an exact integer must be treated as a umask. > Where current-directory would be initialized to (posix-current-directory) and current-file-permission-mask would be initialized to 0. The OS kernel inescapably applies the process umask on top of the Scheme per-thread umask. I don't think the process umask can be overridden (in the way that the process working directory can be overridden by using an absolute pathname instead of a relative one). How do we communicate to users of SRFI 170 that the process umask is the law and the per-thread umask is just something extra? The Scheme implementation could zero out the process umask at the start, but it doesn't help that much since users can change it back at any time... Initializing the Scheme umask to 0 as you suggest would make it so that only the process umask is in effect by default. That seems reasonable. > Then (open-XXX-file <path>) would use the current-directory parameter and the current-file-permission-mask and the posix-current-file-permission-mask (combined with bitwise or). Yes. (current-file-permission-mask and posix-current-file-permission-mask would be combined implicitly by the OS kernel.)
