Good news Re: [Patch] Enable multi-threaded POP3 retrieval

Jack <[email protected]>
Newsgroups gmane.comp.gnome.apps.balsa
Message-ID <[email protected]>
On 2018.01.06 17:47, Jack wrote:
> 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.

Sorry to reply so quickly to my own post, but I think the news is  
actually much better than I thought.  First, I noticed that although  
the "Checking Mail" dialog is still displayed, the "Check" mail icon  
becomes enabled again after the time-out error popup, and clicking it  
briefly adds the other two mailboxes to the dialog.  Those two  
disappear (I assume as soon as their check returns no mail) but the  
same four remain displayed.  In addition, switching all mailboxes from  
TLS to POP3S eliminates the timeouts.  I have no idea whether any of  
these servers should be able to handle TLS (I thought they all did) but  
at least I can now collect mail without waiting interminably for  
timeouts.

The only actual remaining issue with this patch, then, is that if a  
mailbox fetch gets a "Socket I/O timed out" error, the entry for that  
mailbox is not removed from the dialog.  (Clearly, just hitting the  
"Hide" button is an adequate workaround.")  A minor annoyance, perhaps,  
but not really serious.

Albrecht - thanks for all the work on this, and sorry for all the  
interim problems in getting through it.

I'll have to try another clean build to see if the marshalling related  
error remains for me or not.

Jack
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.