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