Offlineimap 6.3.3-rc1 hangs
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 ...
> 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
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 :)
More information about the OfflineIMAP-project