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

[Marcus Brinkmann]

At Thu, 14 Apr 2005 09:01:55 -0400,
Igor Belyi <gpgme at katehok.ac93.org> wrote:
> Yes, on UNIX this waitpid will return immediately with ECHILD errno, but 
> it was added for Win32 benefit since it does not use double-fork. I know 
> that Win32 does not have kill implemented yet but when it does this 
> waitpid will come handy. :o)

Then the W32 port needs to be changed :) Or the code must be
conditionalized by putting helper functions in the *-io.c files.

> The patch intent is to send the spawn gpg process a signal which is a 
> little bit more substantial than closed pipes.

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.

Thanks,
Marcus