[Imaplib2-devel] imaplib2 debugging

[Sebastian Spaeth]

On Sat, 07 May 2011 10:37:45 +1000, Piers Lauder <piers at janeelix.com> wrote:
> I have committed a new version of imaplib2 with extra logging, and a
> new paremeter to the class 'debug_buf_lvl' (default: 3), that controls
> log buffering.
> 
> So, to invoke IMAP4 with output to stderr at logging level 3, one would
> invoke as:
>   IMAP4(..., debug=3, debug_buf_lvl=2)

Thanks, I see that  debug=3, debug_buf_lvl=2, we would not actually log
_log(3,... messages, but we would add them to the circular buffer of 20
last debug messages, right?

> More lock traces now come out at debug level 3, which involved much less
> output than level 5 (which traces actual I/O).

Uhh, we probably should reduce our default logging level to 4 (it is 5
now in cases we have debug turned on).

> Hope that helps...

One question, in _log() you have:
                self.debug_lock.acquire()
                self._mesg(line, tn)
                self.debug_lock.release()

So you have a per IMAP-instance lock protecting from concurrent writes
to stderr. However, given our multithreaded, multiconnection nature, we
can (and do) and multiple IMAP instances running simultanously, and they
share the same log file (debug_file). I am not sure this could cause
hangs, but could certainly lead to corrupted debug output, can't it?

Sorry, threads and locks give me the creeps and make my head hurt :).

I will propose a patch to offlineimap, reducing our default debug level
and updating imaplib2 to the latest and greatest. As we plan to
introduce the IDLE support very soon. I see you have locking fixes for
IDLE too, are they crucial?

Thanks,
Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110507/aa36739c/attachment-0001.sig>