Can you give a reason why you need this?

Old plain fork is expensive, even on Linux, maybe because of garbage
collector.

https://github.com/zalora/defnix/commit/987a49aa77be5596ec2a352c1c758bce532b
5818
https://github.com/zalora/nix-
exec/commit/ea6eb396f0fa67df6568e1bf5dada41fb70a6ca2

That would be a large change which for sure would introduce a lot of new bugs.
In comparison to other operations required for gpg startup the pissible speedup
between fork and vfork will be minor. In any case vfork is an ugly hack which
is not required on modern OSes with MMU. Using posix_spawn is not possible
because we do double forking.

If you have a real problem with the performance, we should first evaluate the
problem and then find a solution. Thus: Please describe the use case and why
you think that the process creation is the performance hog. GPGME has been
designed to overcome such performance problems by eventually introducing
co-porcesses so to fork gpg only once for many operations. We do this with
gpgsm already but have not yet seen an urgent need to also also change this for
gpg. However, if there is a real need for it we can do that.

My point is not speed of forking, but memory pressure. We have problems with
Nix package manager forking any apps, unless it uses vfork() (either
directly, or indirectly via posix_spawn).

If zombies are the only reason for double forking, there are other ways
around, e. g. ignoring SIGCHLD.

And speaking of bugs, don't we have tests? :-)

Sorry, I don't understand why you have a ENOMEM problem there. You are using
Linux and thus you have copy-on-write which should not lead to such problem.
Right there are some corner cases but I doubt that they kick in here.

What kind garbage collector are you using? Can you check with the guix folks
whether they have a similar problem? IIRC, Guile also uses gpgme

You can't use SIGCHLD in a library.

Did you asked on the GUIX list whether they have a similar problem?

ANy news?