I have already created a pthread patch for dbmail although it is directly against the 2.0 series. I find it rather experimental, and some other side effects...
On Mon, Sep 27, 2004 at 08:36:56PM +0200, Paul J Stevens wrote: > Matthew T. O'Connor wrote: > > >When was it decided that we are "going multithreaded". > > No decision yet, afaik. I'm guessing Aaron's just getting exited about the > idea... We're all mostly just awaiting the results from Leifs efforts, so > we cn run our own performance checks. Seeing is believing, indeed. > > >All I have read > >is that Leif is working on a patch that includes a pthreads > >implementation. I have yet to see any evidence that the results are > >worth the effort. Remember that the additional effort is not just the > >initial implementation but also includes the additional maintenance > >since threaded code is more complicated and bugs more subtle and harder > >to track down. > This is already a problem with dbmail, before you introduce threads, thus the reason why I haven't release my pthreads patch. Dbmail code base is so ridiculous to debug that it should be addressed before threads. DBMail needs to be much simplified with a lot of cleanups. > Being somewhat intimate with the current imap codebase, I'm skeptical it > can be done in a clean and maintainable manner. But given the size of the > diff Leifs mentions, perhaps he has solved some of the problems I myself > have been wrestling with :-) > I have some speculation there are some bottlenecks in the imap parser. It maybe a good suggestion to look towards using bison and creating a full fledged grammar parser that can interpret commands and reduce the amount of logic code with dbmail's own parser. Not to mention that it would probably be a bit easier to maintain. Dan
signature.asc
Description: Digital signature
