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

Igor Belyi gpgme at katehok.ac93.org
Thu Apr 14 18:18:55 CEST 2005


Igor Belyi wrote:

> I'll try to look in GnuPG then to see why it doesn't stop or if it is 
> fixed in CVS already.

And the sad story is that it will never be fixed in stable GnuPG... :o(

All cipher generators use the following function to report their progress:

static void
progress( int c )
{
    if ( progress_cb )
	progress_cb ( progress_cb_data, c );
    else
	fputc( c, stderr );
}

See the missing check for an error and no status return from the call?
That means that there's a lot of places in need to be changed to let generation
process notice that the output pipe is closed.

I've tried to look through GnuPG Development branch but its switch to libgcrypt
made it harder for me to see the impact of closed pipes.

On the other hand, stable GnuPG code does have a handler for TERM signal and
therefore soft kill used by GPGME should not cause keyring corruption at least.

I don't know what to do...

It looks like double-fork is a good way to avoid having SIGCHLD handler but
seeing that there's too much changes are necessary in GnuPG itself to make it
react promptly on closed pipe, I would think that sending a TERM signal is a
good alternative for now. And probably waitpid can be removed since it doesn't
work now anyway.

Marcus, I'll let you decide what to do. ;o) But for now if somebody asks me
why Cancel in my code doesn't work I'll refer them to my patch as a workaround.

Cheers,
Igor





More information about the Gnupg-devel mailing list