Re: New mails in mailboxlist

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]