Re: Opening mailboxes

Hello Peter,

On 2/18/20 11:00 AM, Peter Bloomfield wrote:
Hi All!

Balsa gives the startup option of opening every mailbox that was open at the end of the previous session: "Remember open mailboxes between sessions". Because opening a mailbox can be time-consuming, the operations are carried out in threads, but to avoid overloading the machine, a mutex is used to actually execute only one thread at a time.

I've just pushed to GitLab a different approach, using a pool of threads managed by GLib, which simplifies much of the process. To mimic the previous strategy, the pool actually has just a single thread, so that mailboxes are opened in turn. We could be less conservative: GLib can report the number of "processors" available (4, on my laptop), and any number of threads up to that could presumably be used without overloading the machine. That would give the user a responsive UI sooner.

Any thoughts about the number of threads?


Even on my previous, single processor PC, I don't recall noticing any great delay or lag in starting up Balsa, and I keep six to nine mailboxes open, most with dozens to hundreds of messages, but two with over 2000 messages each.  I suspect this will only be a problem on older, smaller, lower powered PCs.

That said, the issue of how many threads to open is also asked when compiling - the -j option to make (I don't remember if make actually handles it or passes it to gcc.)  It also exists at a higher level on Gentoo, telling emerge (the package manager) how many packages it can install (including compile) at the same time.  The distcc docs also discusses the same thing.  All seem to use both the number of threads as well as a maximum load average at which to start a new job or thread.  Most of them seem to suggest a thread count of somewhere between then number of cores to twice that plus one or two, which sounds to me like it's getting to be a religious argument.

The one thing I'm sure you thought of - these mailbox opening threads are unlikely to be compute bound, but might well be IO bound, especially if all the mailboxes are on the same physical disk.  Too bad there isn't an IO equivalent of load average. However, given this issue, I'm not sure allowing multiple threads will actually speed up the overall process.  I'm also not sure how easily this can be tested, given the possibility of disk caching. I'm certainly willing to do some testing, if it's likely to be at all useful.  (I currently use mirrored spinning rust, no SSDs yet.)


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