unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Andrew Whatson <whatson@gmail.com>
Cc: hylophile@posteo.de, 59321@debbugs.gnu.org
Subject: bug#59321: ice-9's open-input-pipe is unexpectedly slow on some systems
Date: Sun, 20 Nov 2022 18:24:57 +0100	[thread overview]
Message-ID: <87r0xx5yja.fsf@gnu.org> (raw)
In-Reply-To: <CAPE069fJ0DRHv7b+mwwqOM22LJtWtUTMAJcDEAUCTbhSmO-abQ@mail.gmail.com> (Andrew Whatson's message of "Fri, 18 Nov 2022 14:49:05 +1000")

Hi,

Andrew Whatson <whatson@gmail.com> 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?

Similarly, with commit a356ceebee000efe91a2a16dbcaa64d6c6a3a922, it’s
possible to pass ‘open-file’ a flag that corresponds to O_CLOEXEC, which
wasn’t possible before.  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.

Ludo’.





  parent reply	other threads:[~2022-11-20 17:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 18:06 bug#59321: ice-9's open-input-pipe is unexpectedly slow on some systems hylophile
2022-11-18  4:49 ` Andrew Whatson
2022-11-18  5:52   ` tomas
2022-11-20 17:24   ` Ludovic Courtès [this message]
2022-11-20 19:00     ` tomas
2022-11-21  4:22     ` Andrew Whatson
2022-11-26 14:39       ` Ludovic Courtès
2022-12-08 12:02         ` Andrew Whatson
2022-12-08 14:34           ` Ludovic Courtès
2023-01-13 15:37           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0xx5yja.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=59321@debbugs.gnu.org \
    --cc=hylophile@posteo.de \
    --cc=whatson@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).