[GPGME PATCH] core: Restore get_max_fds optimization on Linux
alon.barlev at gmail.com
Tue Sep 19 17:53:56 CEST 2017
On 19 September 2017 at 18:42, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Sat 2017-09-16 04:17:19 +0100, Colin Watson wrote:
> > 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
> >> assumption.)
> > 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 support adoption of this patch in GPGME upstream. It addresses a
> pretty severe performance degradation in GPGME on Linux platforms that
> was introduced between version 1.8.0 and 1.9.0.
Just a question...
What about of a solution of fork/exec a wrapper that closes handles
then exec the actual binary?
This wrapper may be considered as "trusted" and as it is exec-ed it
can use any library call.
More information about the Gnupg-devel