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

[Igor Belyi]

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.

>Thanks,
>Marcus
>  
>
Cheers,
Igor