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:
pgp1UpSWSqSnE.pgp
Description: PGP signature