Timo Sirainen put forth on 3/16/2010 6:37 AM:
On Tue, 2010-03-16 at 02:45 -0500, Stan Hoeppner wrote:
Concentrate on rewriting imapd into a threaded model, and get it right.
I could give a lot of reasons for this, but: no.
Ok, what am I missing? Given the current clone/fork imap parallelism architecture, wouldn't spawning imap worker threads from a master imap process be the most straightforward change to accomplish the process count shrink? With the least code changes, and thus be least likely to introduce new bugs?
Maybe I didn't read your previous post correctly. It sure sounded like worker threads were exactly what you were describing. If you're not looking at threads, can you briefly describe the program flow and subroutine layout of the new imap server process(s)? You've got me really curious about this now since you're not looking at threads.
If you don't clone/fork or threads, how else can you get decent parallel client scalability? Are you looking at nested fast looping serial code, and using AIO to minimize stalling the loops due to blocked I/O?
-- Stan