Hi! > On 06/13/2012 01:02:46 PM Wed, Peter Bloomfield wrote: > > Balsa's gtk3 branch has seen some recent work to move calls to Gtk methods out of subthreads and into the main thread. […] > Those changes led to thread-locking issues that have no obvious solution. They have been reverted, […] I suppose this refers to the problems I reported back in June and July: https://mail.gnome.org/archives/balsa-list/2012-June/msg00011.html Anyway, it led me to have a fresh look at the issues, and hurray!, I discovered something: Disabling the configure option "--with-ssl" appears to be the root of all evil. For when I checkout a git commit from the beginning of July* and build it "--with-ssl", the thread-locking does not occur. Also, the most recent commit runs fine "--with-ssl", while with SSL disabled it keeps asking for my IMAP password for one account, while another account fails to load silently. For the record, I can still reproduce the thread-locking with the old commit and SSL disabled. * http://git.gnome.org/browse/balsa/commit/?h=gtk3&id=093c0f9549f7cb493fe1c9d259ecec361e4eefaa (randomly picked) More concisely put: – July + no SSL = thread-locking – July + SSL = OK – most recent + no SSL = connections fail, program does not crash – most recent + SSL = OK The reason that I built balsa without SSL support in the first place was that it was disabled by default and apparently I didn't have a close enough look at the configure options. Should SSL be enabled by default, maybe? By the way, a hint to this was right in our face: The IMAP log in the very first message I posted in June (link above) contains the line: IMAP S: 2 NO [ALERT] This user account is configured to require that all IMAP sessions be connected over SSL. Maybe this helps figuring out the thread-locking mystery? I am happy to help with further testing. Carlos
Attachment:
signature.asc
Description: PGP signature