aborting (or finishing) pending operations in GPGME

[Marcus Brinkmann]

On Tue, Jan 15, 2002 at 05:06:23PM +0100, Stephane Corthesy wrote:
> This  
> non-thread-safeness should be emphasized somewhere in the docs (which  
> docs ;-? even if we know that gpgme is in alpha stage.

It will be.  As about the lack of docs, you are in for a surprise :)
[hopefully tonight]

The thread support Werner added seems to reach as far as was necessary to
get it running under a well known, but cumbersome operating system that
required threading to implement select().

> > My initial idea was to pull those interfaces so we can prevent a soname 
> > change when we add a proper interface.  But if you find them  
> > useful (or they are probably already used by some code), we better fix
> > the few issues they have and keep them.  The things I would like to fix
> > is getting at the result and resetting the pending flag.
> 
> I don't use yet op_start calls; I just _tried_ to wrap them in ObjC  
> methods, with threads, and found it didn't work correctly (I was  
> missing things like operation result...).
> Please feel free to remove the op_start calls from the interface.

The lack of threading support is certainly a good reason to not let users
fall into the trap and to remove them until that is done seems to be
appropriate.  Adding them later is a simple thing to do, and doesn't
require a soname change.  OTOH, I am by now convinced that I can fix
the few problems you had easily (except the actual thread support ;),
so if someone complains I am prepared to keep them.  We are talking
about these functions:

GpgmeCtx   gpgme_wait (GpgmeCtx c, int hang);
GpgmeError gpgme_op_encrypt_start ( GpgmeCtx c,
                                    GpgmeRecipients recp,
                                    GpgmeData in, GpgmeData out );
GpgmeError gpgme_op_decrypt_start ( GpgmeCtx c, 
                                    GpgmeData ciph, GpgmeData plain );
GpgmeError gpgme_op_decrypt_verify_start (GpgmeCtx c, 
					  GpgmeData ciph, GpgmeData plain);
GpgmeError gpgme_op_sign_start ( GpgmeCtx c,
                                 GpgmeData in, GpgmeData out,
                                 GpgmeSigMode mode );
GpgmeError gpgme_op_verify_start ( GpgmeCtx c,
                                   GpgmeData sig, GpgmeData text );
GpgmeError gpgme_op_import_start ( GpgmeCtx c, GpgmeData keydata );
GpgmeError gpgme_op_export_start ( GpgmeCtx c, GpgmeRecipients recp,
                                   GpgmeData keydata );
GpgmeError gpgme_op_genkey_start ( GpgmeCtx c, const char *parms,
                                   GpgmeData pubkey, GpgmeData seckey );
GpgmeError gpgme_op_delete_start ( GpgmeCtx c, const GpgmeKey key,
                                   int allow_secret );

Note that I will definitely break the ABI with the next release, as there
are some small bugs (insignificant, like an off_t where a size_t should be).
So if we should go on a diet, then now.  I am unfortunate to force
recompilation so often, but I try to keep necessary changes in the user
programs to a minimum.

There will be a new function gpgme_op_trustlist_end to match
gpgme_op_keylist_end.

gpgme_cancel will be kept either way because it is useful in a callback function.

If I remove the above functions, there will be no gpgme_op_result or
anything like that, and if we make gpgme_wait to reset the pending flag is
then an internal decision.

[about gpgme_wait resetting pending]

> gpgme_cancel() should do it.

Yes, it could do it, too, if you see it that way (you could even eliminate
the cancel flag, and just check the pending flag in gpgme_wait).  I was
interpreting gpgme_cancel more like a cancellation of gpgme_wait, but the
comment suggests it a bit differently.

[about last result]

> Couldn't gpgme_get_op_info() do the trick?

Not without changing the interface.  Currently, it can only return an XML
string and is only used by encrypt to inform about invalid recipiant and
by sign to report invalid signers.  Adding the error status of the operation
would work, but it seems to be cumbersome to me to retrieve it from there.

Of course, gpgme_get_op_info could take a new argument, a GpgmeError *result.
And then we can also fix it so that it only returns the string if a char **
argument is not NULL (so you can select which of them you want).

> Talking about gpgme performances: did anyone make some profiling on  
> gpgme calls and can tell me why it takes so long to enumerate the  
> whole pubring? Listing keys with gpg is very fast, whereas with  
> gpgme_op_keylist_XXX() it's soooooo slow.

It is?  Thanks for the report.  I don't see an apparent reason why it should
be much slower, but I can find out.  Added to the TODO list.

> Thanks for your reply,

Your feedback is welcome, and very important to us.  Keep it up!

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus at gnu.org
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de