gpgme_cancel() does not stop gpg process from finishing
gpgme at katehok.ac93.org
Thu Apr 14 13:51:14 CEST 2005
Marcus Brinkmann wrote:
>At Tue, 29 Mar 2005 18:51:11 -0500,
>Igor Belyi <gpgme at katehok.ac93.org> wrote:
>>[1 <text/plain; ISO-8859-1 (7bit)>]
>>Starting asynchronouse call and then canceling it with gpgme_cancel do cause gpgme_wait() return Canceled error but leaves gpg process working and finishing the call. I have a slightly modified t-genkey test which shows that the key is generated after cancelation. I can send it if you want to.
>This is true. We use a double-fork technique to separate the child
>from the parent process and then just close all file descriptors.
>>I also have a patch (attached, since it's very small) fixing the problem in GPGME 1.0.2. :)
>The waitpid is wrong, because GPGME is not the parent of the process
>(due to the double-fork).
If you look at the patch - it gets pid from the child in the GPGME child
process and then pass it back to GPGME using a pipe. This is the pid
return from posix_io.c/_gpgme_io_spawn() and not the pid of the GPGME
child. It does work for me and gives more control to GPGME over the
process is spawn.
>FOr most operations, current behaviour should be OK. Even for genkey:
>GnuPG is supposed to send a heart-beat every second, so it should
>notice that the status FD is closed within the next second and then go
>away. Maybe the current GnuPG versions don't do this, but they should.
>Maybe you want to check that one out?
I've created the patch since I noticed the problem with GnuPG not
canceling process when pipes are closed during gpgme_op_genkey. I still
think that GPGME can handle such situation even if GnuPG behaving
incorrectly in your opinion. But, it's your code and your decision -
I'll just keep applying the patch on my box.
More information about the Gnupg-devel