CFT: fix OfflineIMAP lockup in single-threaded mode
nicolas.s-dev at laposte.net
Sun Jan 27 19:39:13 GMT 2013
On Sun, Jan 27, 2013 at 09:13:28PM +0400, Eygene Ryabinkin wrote:
> From the
> exitthreads = Queue(100)
> inside offlineimap/threadutil.py. The thing is that each
> ExitNotifyThread pushes itself to this queue upon exit to save exit
> notification. And without exitnotifymonitorloop() that consumes these
> notification the queue will be full after 100 clients. And since each
> InstanceLimitedThread is the child of the ExitNotifyThread and it
> acquires the BoundedSemaphore on its start(), there will be a
> situation when such thread will be trying to put itself to the
> 'exitthreads' and the queue will be full and that thread will exhaust
> the BoundedSemaphore, so no new threads will be spawned before it will
> exit, but it can't, since it waits for the next free slot in the Queue
> that isn't cleaned.
Can't say whether the patch really fixes the issue but it's very
pleasant to see work like that and activity on the repository in general
(like Dmitrijs did recently).
> One thing that worries me currently is the way that options.singlethreading
> is propagated from the main code: adding new pseudo-item to the 'general'
> configuration section isn't that good. Something like the singleton that
> will provide read-only access to the options is a better way, in my view.
Well, as long as contributors and users are aware of what's going on and
as long as whatever is released as stable is not experimental stuff,
everything should be ok.
So, about this subtle and critical topic I'd say it's fine to go step by
step. This would prevent from non-required headaches and could later
help to distinguish newly introduced issues coming from the "core" fix
and the "polishing" commit.
> Fine. I had started to get through all open bugs at GitHub and trying to
> fix them.
Thank you for your work on OfflineIMAP. Resurrecting such non-obvious
and important issue is very welcome.
More information about the OfflineIMAP-project