[GPGME PATCH] core: Restore get_max_fds optimization on Linux

[Colin Watson]

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 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...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: not available
URL: </pipermail/attachments/20170916/bb10a682/attachment.sig>