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

[Igor Belyi]

Marcus Brinkmann wrote:

> I understand that intention, and it's a good one. Let me first say
>
>that _if_ we go that route, then there is little sense in
>double-forking, but instead we should just fork once and then call
>waitpid always.  This is what old versions of GPGME did, but then you
>need a SIGCHLD signal handler, too, and that's a bit of a mess in a
>library.
>
>I really like the beauty of double forking and not need to worry about
>what happens to GnuPG after closing the file descriptors, and just
>have GnuPG deal with it properly.  This is useful in GnuPG anyway, so
>nothing is lost, and it makes GPGME simpler.  This is why the code is
>like it is.
>
>Even better, but for future development, would be to have a special
>file descriptor or other communication channel by which we can send
>asynchronous events like cancelation to GnuPG.  Then GnuPG could
>listen on that channel.  Much more graceful than kill(), you wouldn't
>even need to exit if you are in server mode, and want to run many
>operations after another with the same instance of GnuPG.
>  
>
As much as I hate to admit it I think you are right - using kill() in 
gpgme does look more like a hack than a solution if you want to reuse 
GnuPG instance in a future. I'll try to look in GnuPG then to see why it 
doesn't stop or if it is fixed in CVS already.

Thanks,
Igor