After patching the above mentioned if-clause the command fails on the first try, but it succeeds on the second try

$ gpgconf --kill all

A fix has been released; see T5052.

I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.

Indeed, I think this might be a driver problem.

I don't see any problems in your PC/SC log, at all. If it is the failure of vendor's driver, we actually have no way to fix.

I know these troubles.

I have been able to resolve the problem by writing:

In T3189#117959, @gniibe wrote:

Do we need to expose the secmem routines, as a public interface of gpgrt?

I would find it useful. For example I'm making a utility that gets a passphrase with GPGME and gpg-agent, and would like to copy it into a buffer that lives on after closing the context.