Hi Albrecht!

On 01/14/2020 01:44:00 PM Tue, Albrecht Dreß wrote:
Hi all,

since the latest updates of master I observe that Balsa /sometimes/ after startup 
consumes 100% CPU, and does show nothing in the open mailbox tabs.  I could 
reproduce the issue in gdb (see below); the thread consuming the 100% CPU load is 
the main one (thread 1).  It is still possible to regularly terminate Balsa by 
clicking the main window close button (but File -> Quit does nothing).  I 
*think* this error was introduced last Sunday (Jan. 12, 2020), maybe with commit  
e556a72068b2f9eb4acf0d56cf33f3eaedc0a522?

Any idea what is happening here?

Cheers, Albrecht.

Apparently an idle handler that was tasked with completing the load of a 
mailbox was being constantly rescheduled. Weirdly, it was only for an empty 
mailbox--loading a mailbox with messages caused no problem!

That part of the code handles scrolling to an appropriate message. An empty 
mailbox doesn't have any message to scroll to on opening, so I just put in some 
code to bypass it; works for me right now without hogging the cpu. Just pushed 
to GitLab.

I'm trying to move the time-consuming stuff to threads, to make the UI more 
responsive, and perhaps even make the progress bar move again when setting the 
fraction of a task completed. I also want to look into using a GThreadPool[0], 
to make a limited number of additional threads available for the initial 
opening of mailboxes.

Best,  Peter

[0] https://developer.gnome.org/glib/stable/glib-Thread-Pools.html

Attachment: pgpRQRUJlGvc4.pgp
Description: PGP signature

_______________________________________________
balsa-list mailing list
balsa-list@gnome.org
https://mail.gnome.org/mailman/listinfo/balsa-list

Reply via email to