Re: user processing delays with IMAP folders
On Tuesday, 04 April 2006 at 23:26, Phil Pennock wrote:
> As a heads-up before the next release: earlier today I finally tracked
> down why mutt appears to "hang" and not respond sometimes at when at
> work.
>
> I'm subscribed to 127 folders, many of which rarely get new mail. Mutt
> fills up the IMAP command queue and hangs waiting for it to flush; it
> then supplies more IMAP commands without stopping to deal with user
> interaction or changing the folder.
>
> As a result, I can end up waiting quite a while whilst mutt "hangs".
>
> Behaviour cause confirmed with watching ~/.muttdebug0 grow; work-around
> is: set mail_check=32767
>
> I had previously tried raising IMAP_PIPELINE_DEPTH, but only to 50 and
> it didn't help; having seen the actual behaviour, I'm dubious that
> raising it to 150 would help, since it looks as though mutt just hangs
> waiting for the response. However, it might be that it's only hanging
> because it's trying to queue commands. Can anyone confirm that this
> might be true and that it's worth trying to lengthen the pipeline that
> far?
Raising the pipeline depth to fit all mailbox polls into one send
might help, since as you noticed mutt must wait for some previous
command to complete before sending a new one. Trying to interleave
interactions (and other IMAP commands) while a current command is
executing is probably a lot trickier - I for one am in no mood to
attempt it now...
my workaround would have been to not subscribe to 127 folders. I think
on lots of other mail clients that would involve opening up 127
separate TCP connections :)