Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRFI 170: POSIX API #13

Open
lassik opened this issue Jan 3, 2020 · 5 comments
Open

SRFI 170: POSIX API #13

lassik opened this issue Jan 3, 2020 · 5 comments

Comments

@lassik
Copy link
Collaborator

lassik commented Jan 3, 2020

I can start implementing this. The SRFI hasn't been finalized yet so any major problems in the spec can still be fixed.

Gambit keeps track of the current directory per thread whereas 170 uses the standard Unix per-process CWD. Does that require special considerations in the implementation?

Otherwise things ought to be fairly straightforward.

@feeley
Copy link
Member

feeley commented Jan 3, 2020

Gambit's current-directory is a parameter object that is disconnected from the process' CWD managed with chdir and getcwd. That's so Scheme threads can have distinct bindings for their current-directory. Gambit's runtime system does call chdir and getcwd to implement path-normalize (but it restores the previous CWD). However, this will have to be protected with a mutex in an SMP setting if other code can call chdir.

@lassik
Copy link
Collaborator Author

lassik commented Jan 3, 2020

Hmm. In the SRFI, only set-working-directory changes the process CWD. However, there are several procedures that take pathname arguments. Should those use the global process CWD or the parameter CWD? What about C libraries called via the Gambit FFI - when those libs deal with pathnames, they are going to be relative to the process CWD, right?

@lassik
Copy link
Collaborator Author

lassik commented Jan 3, 2020

More generally, this concern affects all SRFIs that take pathnames.

@feeley
Copy link
Member

feeley commented Jan 4, 2020

chdir and OS threads are simply incompatible (because the CWD is a per process thing so shared by all OS threads). So defining filesystem access procedures that are sensitive to the per process CWD makes it impossible to use those procedures effectively in a multithreaded Scheme system. That's why Gambit uses a distinct current-directory parameter object that can have a per Scheme thread binding and relative paths are interpreted relative to the Scheme thread's current-directory.

The fundamental question is "what is SRFI 170 trying to achieve"? If the answer is "an interface to posix functions such as chdir, open, etc" then that is fine, but it shouldn't presume that there is a link between the posix open and the Scheme open-input-file, the posix relative paths and the Scheme relative paths, etc

Anyway, in Gambit there is (path-normalize path) that can be called to turn the (possibly relative) path into an absolute path (using the current-directory parameter object if the path is relative), and the absolute path can be passed to the posix open in order to avoid being dependent on the process CWD.

@lassik
Copy link
Collaborator Author

lassik commented Jan 25, 2020

Your arguments make sense. It may be best to add some language to SRFI 170 so that the implementation is allowed to use a per-thread working directory. I'll start a thread (heh) about it on the SRFI's mailing list once I get the spare energy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants