Re: New mails in mailboxlist

[Willem Riede <wriede riede org>]

On 05/29/2005 12:56:43 AM, Peter Bloomfield wrote:
> On 05/27/2005 06:29:54 PM, Willem Riede wrote:
> [ snip ]
> > I have on occasion wondered (but never investigated) how much > work it  
> would be to have the mail checking (and fetching?) be > done by a separate  
> thread, so that the GUI would never have to > "freeze"...
>
> Oh, it *is* done in a subthread--but the subthread may need to lock the  
> mailbox while it updates it, or likewise lock the display, so it can still  
> interfere with the UI.
>
> Possibly Balsa is too conservative in these locks.  On the whole, I guess,  
> we err toward the conservative--some scrutiny of these practices would be  
> great!

That subthread appears to be created in check_new_messages_real and proceeds  
to execute check_messages_thread, which calls libbalsa_mailbox_check through  
balsa_window_mailbox_check for each mailbox to check.
Like "HACKING" prescribes, the GDK lock appears to be taken during the entire  
process, except possibly briefly while waiting to obtain a lock on the mailbox  
at the start of libbalsa_mailbox_check.

Significant is that the GDK lock is taken while the imap server query is in  
progress (for those of us like me that access our mail on an imap server the  
check method of the mailbox class is libbalsa_mailbox_imap_check, for which  
the main action is in lbm_imap_check).

I submit that that is a bad idea, as that can take any amount of time, during  
which the GUI is locked, as the "freeze" we've been talking about  
demonstrates. Shouldn't any balsa thread ony hold the GDK lock while  
manipulating GUI components? For the shortest possible interval only limited  
by our cpu speed?

If you agree, can we drop the GDK lock after we gained exclusive control of a  
mailbox in libbalsa_mailbox_check and picked up anything we need from G[DT]K  
structures until the point where we are done talking to the imap server and  
get ready to make G[DT]K calls again?

Regards, Willem Riede.