[GPGME PATCH] core: Restore get_max_fds optimization on Linux
cjwatson at debian.org
Sat Sep 16 05:17:19 CEST 2017
On Sat, Sep 16, 2017 at 04:16:44AM +0100, Colin Watson wrote:
> * src/posix-io.c (get_max_fds): Restore Linux optimization, this time
> using open/getdents/close rather than opendir/readdir/closedir.
> opendir/readdir/closedir may allocate/free memory, and aren't required
> to do so in an async-signal-safe way. On the other hand, opening
> /proc/self/fd directly and iterating over it using getdents is safe.
> (getdents is not strictly speaking documented to be async-signal-safe
> because it's not in POSIX. However, the Linux implementation is
> essentially just a souped-up read. Python >= 3.2.3 makes the same
Incidentally, on my system, this reduces the time required for "make -C
tests/gpg -j4 check" from 42 seconds to 6 seconds. How dramatic this
difference is will of course depend on the value of the hard limit for
RLIMIT_NOFILE ("ulimit -Hn"), which on my system is 1048576 by default,
although I haven't bothered to hunt down where that default is set; with
a more traditional hard limit of 4096 the difference is negligible.
I noticed this because some tests of the launchpad.net codebase that
exercise GPGME were timing out in my test container. I thought about
capping our hard limit for RLIMIT_NOFILE to something more reasonable,
and that might still make sense, but I think there's more global benefit
in improving GPGME.
Colin Watson [cjwatson at debian.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 897 bytes
Desc: not available
More information about the Gnupg-devel