[GPGME PATCH] core: Restore get_max_fds optimization on Linux

[Alon Bar-Lev]

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.

Hi,

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.

Regards,
Alon