Hi Andrew, Andrew Whatson <what...@gmail.com> skribis:
> Ludovic Courtès <l...@gnu.org> wrote: [...] >> 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. OK. [...] > We also need equivalent functionality around SOCK_CLOEXEC. It seems > this is implemented for ‘accept’, but not ‘socket’ or ‘socketpair’. It’s possible to use SOCK_CLOEXEC with ‘socket’ and ‘socketpair’ already, as in: (socket AF_INET (logior SOCK_CLOEXEC SOCK_STREAM) 0) With commit 1d313bf5f0d296d766bd3a0e6d030df37c71711b, ‘pipe’ is also covered. So I think we have pretty much everything we need, at least starting with 3.0.9. > 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. The patch LGTM; it’s certainly an improvement on systems configured with a high per-process FD limit. Now, I believe use of ‘posix_spawn’ as proposed in <https://issues.guix.gnu.org/52835> makes that unnecessary. Let’s take a closer look at that other patch and so we can see… Thanks, Ludo’.
