Re: [Patch] Enable multi-threaded POP3 retrieval

[Jack <ostroffjh users sourceforge net>]

On 2018.01.03 10:11, Albrecht Dreß wrote:
> Hi all,
>
> attached is a larger patch which enables multi-threaded retrieval of  
> POP3 messages.  The biggest part of the patch is related to changes  
> of the progress dialogue implementation, though.  It also changes the  
> preferences by replacing the old (retrieve) progress dialogue options  
> by two simple check boxes for enabling the send and receive progress,  
> respectively.  As a side effect, we get rid of a bunch of global  
> variables used for the POP3 progress communication between the main  
> and retrieval threads which is a lot cleaner IMHO.
>
> BTW, the patch removes the (now obsolete) file src/threads.h.  I  
> noticed that the file libbalsa/gforest.c is not referenced everywhere  
> – couldn't we remove it?
>
> As always, any comment is welcome!

(I keep replying to the original, because I don't think there is  
anything important/relevant in my earlier replies.)
I got rid of a TLS related error by changing that server to POP3S, even  
though their configuration instructions say TLS is OK.
With the patch, the checking mail dialog comes up with six entries.   
The one I changed to POP3S and one other disappear quickly, with no  
mail and no errors.  The dialog remains showing with four entries.   
Three are for inbound.att.net, and after a minute or two, I get a popup  
"POP3 mailbox mailboxname: cannot connect inbound.att.net: Could not  
connect to inbound.att.net: Socket I/O timed out (repeated for all  
three mailboxes).  The fourth is for my gmail account.  The Checking  
Mail dialog remains up for at least five minutes past that popup.   The  
debug output has three "DEBUG: finalised connection to inbound.att.net"  
and one "DEBUG: finalised connection to pop.gmail.com" even though  
those entries remain displayed in the dialog.  I see no other entries  
for those mailboxes in the debug output.

I do see "Gtk-DEBUG: State 0 for balsa-message-cite-bar 0x563acc97f210  
doesn't match state 128 set via gtk_style_context_set_state ()" in the  
output, but I have no idea if it is at all relevant.

Is there any other debugging I can do?  I do really like the idea of  
parallel checks, and I'm still hoping that these problems are really  
independent of that, other than perhaps dealing with some funny timing  
issue.

Jack