[Users] Idea - Could we "delay" signature checking on an email ?

[Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)]

Hello,

On Wed, 24 Jul 2013 08:54:47 +0200
Ricardo Mones <ricardo at mones.org> wrote:

> > Anyway, that's what I used to be sure the problem was with Sig checking,
> > and it's the configuration I'm using now... but it's sad to have to
> > deactivate this.
> >
> > If delaying the check is not something easy within Claws architecture,
> 
>   Launching a thread for this shouldn't be difficult, but IMO it would
> only be a speedup for the keys not in the local keyring, so you'd have to
>   provide a way to know that before checking to decide to create a thread
> or just do it like now. This method can rely on gpg, but then it _may_ be
> as expensive as doing the proper check, hence you'd be slowing key
> checking of cached keys a lot. If you don't rely on gpg you'd have to
> implement some table of known keys, going into the nice problem of
> keeping the CM table in sync with gpg one, as gpg can be used by more
> applications than CM. Don't forget to make these threads cancellable, or,
> at least, able to discard their results, because when browsing summary
> view quickly the message view which launched the thread may not exist
> anymore...

Yesterday, I've been playing with vim and browsing the code... I then
switch to run claws in --debug mode, and ended using strace !
The results were quite surprising: the check is already done in a thread...
but it appears that the main app is kindda waiting synchronously for the
result of this thread, so the only "advantage" of threading the control is
the cancellation possibility.

I still haven't figured all the details, but what I saw :
 - main process is pid 15704
 - main process creates thread 15739
 - thread 15739 creates thread 15740
 - thread 15740 does the check - during that time, main process is waiting 

15704 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f61f3683cb0) = 15739
15704 wait4(15739,  <unfinished ...>
15739 set_robust_list(0x7f61f3683cc0, 24) = 0
15739 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f61f3683cb0) = 15740
15739 exit_group(0)                     = ?
15740 set_robust_list(0x7f61f3683cc0, 24 <unfinished ...>
15739 +++ exited with 0 +++
...
15704 select(26, [25], [], NULL, {1, 0} <unfinished ...>

[Process 15740 then goes running - be careful 15740, not 15704]

15740 exit_group(0)                     = ?
15740 +++ exited with 0 +++
15704 <... select resumed> )            = 1 (in [25], left {0, 835383})
15704 select(26, [25], [], NULL, {0, 0}) = 1 (in [25], left {0, 0})
15704 read(25, "[GNUPG:] PROGRESS -&27 ? 0 0\n[GNUPG:] PROGRESS -&27 ? 198 0\n[GNUPG:] PROGRESS -&29 ? 0 0\n[GNUPG:] PROGRESS -&29 ? 1176 0\n[GNUPG:] SIG_ID xxxxxxxxxxxxxxlQTgP1iaOv50M 2013-07-23 1374588809\n[GNUPG:] GOODSIG 6xxxxxxxxxxxE0 Paul Rolland <paul.rolland at witbe.net>\n[GNUPG:] VALIDSIG 6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0 2013-07-23 1374588809 0 4 0 17 2 01 6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0\n[GNUPG:] TRUST_ULTIMATE\n", 1024) = 419

and so main process resumes...

So, right now, it seems we already have some async. processing, but
something is resync'ing....

I'll check more carefully the code, as the "thread" 15740 is exec'ing gpg2 :
15740 execve("/usr/bin/gpg2", ["gpg", "--enable-special-filenames", "--use-agent", "--batch", "--no-sk-comment", "--lc-messages", "en_US.UTF-8", "--lc-ctype", "en_US.UTF-8", "--status-fd", "26", "--no-tty", "--charset", "utf8", "--enable-progress-filter", "--display", ":0", "--ttyname", "/dev/pts/5", "--ttytype", "xterm", "--verify", "--", "-&27", "-&29"], [/* 71 vars */]) = 0

That will probably help me understand what's happening.

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20130724/4759c538/attachment.sig>