Another stab at IMAP IDLE

Leon Bogaert leon at
Fri Jan 21 08:40:51 GMT 2011

When I use self.parent.acquireconnection() the callback isn't fired.
When I setup a connection of my own with imaplib2.IMAP4_SSL() it is fired.

So maybe it's something in the wrapper that blocks the callback. I'll check it with the non ssl variant tonight.


From: at [ at] on behalf of Leon Bogaert [leon at]
Sent: Thursday, January 20, 2011 21:31
To: Ethan Glasser-Camp
Cc: OfflineIMAP-project at
Subject: RE: Another stab at IMAP IDLE

I just tested it. But it looks like the dosync callback is only fired when Idlethread.join() is called in the keepalive method.
So the idle callback is only called when the keepalive method is fired and not directly when a new mail arrives for example.


From: Nicolas Sebrecht [ni.s.nis33 at] on behalf of Nicolas Sebrecht [nicolas.s-dev at]
Sent: Wednesday, January 19, 2011 19:21
To: Ethan Glasser-Camp
Cc: Leon Bogaert; OfflineIMAP-project at; Nicolas Sebrecht
Subject: Re: Another stab at IMAP IDLE

On Wed, Jan 19, 2011 at 09:56:54AM -0500, Ethan Glasser-Camp wrote:
> Hey,
> Regarding current status: I haven't written any code since the last
> patch series I sent to the mailing list. I did spend a lot of time
> tracking down a mysterious hang that eventually seems to be related
> to a multithreading deadlock. It's sporadic so I couldn't nail down
> what exactly caused it, but it certainly might have something to do
> with imaplib2.
> I think the next step is to rewrite the patch series in a more
> approachable form. Nicholas suggested that we not go to too much
> effort to preserve the form of the commits as they were originally
> written, especially the commit messages, so I was figuring to have
> commits for:
> - introducing the newest imaplib2 as a file, but not using it.
> - switching over to it, including any semantic changes that are necessary.
> - introducing IDLE functionality based on the timer hack originally
> implemented by James Bunton in
> .
> Plus whatever else seems necessary. I'm kind of busy for the next
> week or two, so if you wanted to beat the commit series into shape,
> that would be great.

Sounds like a good plan. I would encourage to send small steps, so I can
merge them in pu. Really, I _don't_ expect all such work done off-line.
The first step is the very easy task to introduce the feature and could
be merged soon.

> Since imaplib2 was dropped due to reliability concerns, it seems
> pretty important that we not cause any horrible crashes or hangs in
> switching over to imaplib2. I'd love to have more testers running
> the version of offlineimap that supports IDLE, whether they enable
> it or not.

Yes. I'm definetly more likely to merge such feature if it's optional
and marked as EXPERIMENTAL. The good news is that others could test it
and help on it easily.

>            I'm definitely seeing a sporadic hang on my extremely
> crappy Internet connection, more commonly when the connection is
> overloaded, and if anyone could reproduce that and track it down,
> that would be great.

Nicolas Sebrecht

OfflineIMAP-project mailing list
OfflineIMAP-project at

OfflineIMAP homepage:

More information about the OfflineIMAP-project mailing list