Offlineimap 6.3.3-rc1 hangs

Ethan Glasser-Camp glasse at cs.rpi.edu
Thu Mar 17 18:11:01 GMT 2011


On 03/17/2011 01:47 PM, Vincent Beffara wrote:
> EG>  Is this maybe related to the weird read() implementation in
> EG>  UsefulIMAP4 (imapserver.py)? Can you maybe try to delete that and
> EG>  see what happens?
>
> Yep, that fixes it, nice catch! Hmmm. So it was my 5 line contribution
> to the code that ended up hurting me ...

Great!

> So apparently the only way to fix the program is to remove the hack,
> which in turn means dropping python 2.5 compatibility (rather stability)
> on the mac. But working only on python 2.6 is better than not working at
> all I guess !

I think that what's going on (technically) is that imaplib called 
read(x) to get EXACTLY x bytes, and that imaplib2 called read(x) to get 
AT MOST x bytes (which is more in accord with what read() does in other 
contexts, even file.read()!). So imaplib2 is calling with a fairly large 
size, because it wants to get whatever's available at the time, and our 
read() blocks until it can return exactly that amount. Because the other 
side is waiting for us to send a command, we deadlock.

So it might be possible to continue to support Mac/2.5 if someone with 
access to such a system was really motivated to send a patch :). We'd 
still read in small chunks, but we'd stop at the first short read (and 
hope that a short read doesn't happen to line up with a "chunk" size? or 
maybe return each chunk directly, since it's being read by a nonblocking 
thread?).

But like others said in the recent thread about this code, I find 
special-case code inherently ugly, especially special-case code for OS X 
("Unix under the hood", pah), and I'm more than happy to make OS X users 
install >=2.6. Maybe I'd have a little more sympathy for BSD users :)

Ethan





More information about the OfflineIMAP-project mailing list