Re: Get and set current directory Lassi Kortela 21 Jul 2019 13:44 UTC
> With green threads the binding of the current directory parameter can be copied to the process’ cwd on calls to C funtions (that care about the cwd). This could be done automatically by the FFI, possibly with some hints from the programmer. Many Schemes only have green threads. Some OSes have per-thread cwd's so it's not that simple. You'd have to keep track of each thread's OS and Scheme cwd (and differentiate per OS). On each FFI call, you check which thread you're on, whether the Scheme cwd has deviated from the OS cwd, and do chdir() if it has. FFI functions can call C code that changes the cwd, so Scheme's idea might be wrong. Another problem is the current directory disappearing from underneath. chdir() can fail; if that failure is delayed to an unpredictable FFI point, it can cause confusing error scenarios. More generally, I would try to avoid any unnecessary FFI complications. FFI complexity and non-portability is one classic stumbling block for wider library coverage in languages. (And adds maintenance for implementors.) > It could be part of the spec that (current-directory string) only sets the process’ cwd when not in the scope of a parameterize, otherwise it simply sets the latest binding. So this API (using parameter objects) can express the same cwd mutations as the proposed (set-current-directory! string), but has the advantage of allowing dynamic binding for procedures such as open-input-file that need to resolve relative file names. This means that library code has no way of telling whether the OS or Scheme cwd is being used. Ideally the code shouldn't have to care, but abstractions are leaky. This is unwise on another count as well: A pathname is not a reliable way to refer to the current directory since that directory can be renamed (e.g. finding a shell prompt's pwd messed up after you have moved a directory). It is now possible on many systems to open() a directory and use openat() to parse pathnames relative to that directory, even if it has been renamed or moved. This is often sound practice, esp. in long running daemons. > In any case, in a truly parallel setting, some synchronization is required around the mutation of the process’ cwd whether (current-directory string) or (set-current-directory! string) is used. As far as I can tell, it's not required if we don't have any Scheme variable to synchronize and Scheme simply defers to the OS. This is similar to the situation with file descriptor numbers vs Scheme ports. I would advocate that we don't even attempt to do any fancy abstraction to keep the two worlds in sync and hide the boundary. The ramifications are so complex that we'll never get them right, and it's a decent bet that these things get more complex with every passing decade.