On 3.12.2013, at 0.09, Mike Abbott <michael.abb...@apple.com> wrote: >> Do you think [moving IMAP IDLE connections to a separate imap-idle process] >> would work for you also? > > Probably. It always depends on the details. Forking a new imap process > every time there's a little input to read or output to send might perform > poorly under load. Having a pool of ready imap processes could help that, > when the configuration permits (e.g. all mail owned by one uid). It would be > interesting to compare client_limit > 1 vs. an idle connection aggregator.
I was thinking that you’d have a pool of imap processes waiting and being reused. Some state would be transferred between the imap-idle and imap processes. And it could work also for non-IDLEing idling connections. Then there needs to be some kind of a good balance of figuring out when to move connection to imap-idle to maximize the amount of time it’s there but also to minimize unnecessary CPU-wasting transfers.. Oh, and this would be possible also with multiple UIDs (although imap-idle might have to run as root then). > What's so evil about client_limit > 1 besides requiring one uid, the indexer > polling I mentioned, and broken fcntl-style file locks? Or is that enough? Mainly that there are so many possible reasons for why imap process might block. It’s not possible to make all of them asynchronous. I guess getting rid of the longest waits could help, but I still wouldn’t dare to run that in production.
