gpgme_cancel() does not stop gpg process from finishing asynchronous call

Marcus Brinkmann marcus.brinkmann at
Fri Jun 3 00:48:07 CEST 2005

At Sun, 17 Apr 2005 17:39:48 +0200,
Werner Koch wrote:
> On Sat, 16 Apr 2005 18:03:40 -0400, Igor Belyi said:
> > Additional thought - sending TERM signal should be no worse than a
> > user hitting Control-C while working with gpg directly.
> BTW, there is an easy way to tell gpg to stop: Although the status
> functions won't return an error code, they may be changed to detect a
> write error and call exit() then.  The problem here is that this
> slightly changes the semantics and some software may fail therefore.
> The only way to implement this in a safe way is by introducing a
> new option to gpg to do this.  gpgme may then look at the gpg's
> versions and decide whether to use this option.  Marcus, what do you
> think, shall I add such an option to gpg 1.4.2?

Sounds like a good idea, if there is still time.  Or just to the next
version, it doesn't seem to be that urgent to me.

However, the real solution of course will be to have some pipe (or
signal) that can be used to send asynchronous cancellation requests to
gpg, which then processes it and indicates to gpgme on the status fd
that the operation was canceled successfully.  In server mode that
will be incredibly useful, because it makes cancelation a very clean
and safe operation.


More information about the Gnupg-devel mailing list