Ludovic Courtès wrote: > > Andrew Whatson skribis: > > > Forcibly closing file descriptors like this shouldn't be necessary if > > the application has properly opened descriptors with the FD_CLOEXEC > > flag. It would be good to get input from some more experienced Guile > > hackers on the potential consequences of this change. > > Libguile opens all its own file descriptors at O_CLOEXEC (one omission > was recently fixed in 0aa1a9976fc3c6af4d1087e59d728cb8fe7d369a) so it > may be possible to remove that FD-closing loop. There’s still the > possibility that application bug unwillingly leaks FDs, but we could > consider it’s none of our business. > > Thoughts? I agree with this approach in principle, but from what Tomas is saying it seems like it's not currently possible for applications to do the right thing in all cases. > Similarly, with commit a356ceebee000efe91a2a16dbcaa64d6c6a3a922, it’s > possible to pass ‘open-file’ a flag that corresponds to O_CLOEXEC, > which wasn’t possible before. Nice! > I’ve also been thinking that files opened with ‘call-with-*’ should be > O_CLOEXEC. That’d be an incompatible change though, so maybe not > something for 3.0.x. This sounds reasonable to me. We also need equivalent functionality around SOCK_CLOEXEC. It seems this is implemented for ‘accept’, but not ‘socket’ or ‘socketpair’. Python's PEP 433 contains a good explanation of the issues which can arise from leaked file descriptors: https://peps.python.org/pep-0433/#inherited-file-descriptors-issues Given the risks, I'm convinced that Guile's conservative approach is actually quite sensible. It seems like the best path forward would be to implement platform-specific optimizations where possible. I've attached a draft patch which implements a fast-path on systems where "/proc/self/fd" is available.