[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59321: ice-9's open-input-pipe is unexpectedly slow on some systems
From: |
Ludovic Courtès |
Subject: |
bug#59321: ice-9's open-input-pipe is unexpectedly slow on some systems |
Date: |
Sat, 26 Nov 2022 15:39:06 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Andrew,
Andrew Whatson <whatson@gmail.com> skribis:
> Ludovic Courtès <ludo@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’.