On Thu, 05 Jun 2008 14:33:49 +0200 Tomasz Sterna <[EMAIL PROTECTED]> wrote:
> We were talking with Ono today about merging all jabberd 2 sub > applications (router, c2s, s2s, sm) into one binary, with multiple > threads running each components. > That would mainly reduce maintenance and deployment effort. You would > run one process instead of several ones. I actually don't see that as such a burden. But if it is, there's always the possibility of having a master process that takes care of starting sub-processes according to some configuration, like postfix does it. > And wouldn't keep one from running each component in separate process > - just run only one thread+component in each instance. Why would that be an advantage? Having multiple process can help both, security and stability. > > With such design there are some performance optimisations possible in > router, that could just pass pointers to data instead of pushing the > data through TCP sockets. What about using unix sockets for local connections? Still no zero-copy, but maybe better than TCP. > There are some problems with current single-thread design of jabberd, > but we think they are easily solvable. Ex. static buffers with thread > local-storage. > > What do you think about this idea? > Is it worth pursuing? Or not worth the effort? If performance is really such a big concern, and if data copy is actually the show stopper, one could always use shared memory for communication between two local components. This way you get zero-copy without abandoning the multi process design. Multi threading is always a PITA. You have to care about data protection, which is otherwise done by the OS. It adds complexity as you have to care about race conditions and deadlocks. All of this is also true, of course, if shared memory is used. Cheers, harry
signature.asc
Description: PGP signature
