Paul J Stevens wrote: > I'm taking this to the dev list.... > > Matthew T. O'Connor wrote: > >> This sounds scary to me. Obviously it's not my project and I'm not the >> one coding, I'm just worried as an admin that depends on DBMail that we >> are going to open up a large can of worms for dubious gain. >> > > Matthew, > > Please be asured, I'm not yet convinced we should go for a threaded > model either. > > Aaron and I started looking for a lib for doing connection pooling to > the database. As far as I can tell (http://www.tildeslash.com/libzdb) > is the only viable lib which does this. Using such a setup however would > require threading. And as everyone keeps telling us, that is no trivial > matter. > > Another option to scale up the database connections would be a worker > model where one master process handles all incoming connections using > select or libevent or something similar, and hands over clients to one > of a limited number of forked workers which maintain the database > connections. > > The worker processes would be very much like the current forked > children. The master process would have to do multiplexed IO, and need a > callback infrastructure. > > This approach is actually my favorite since we don't need to make the > whole codebase thread safe to do it. It also feels more like an > incremental change, rather than a complete redesign of the processing > model, which is good imo. > > > My taught is with lots of potential clients your better off having a few worker threads handling them than getting the OS to handle 10000 seperate threads (say number of CPU's * 2 or some other magic number). Theres no inherent reason why a single imap server couldn't handle that many client connections (assuming they all weren't going nuts at the same time)
Should there be that much need for IPC? unless you have shared inboxes why do multiple threads need to deal with the same data?, I assume that transfers from a DB backend to an IMAP front would be by shared memory and some sort of notify event?
_______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
