Just spent some time reading code. Looks awesome! Well done! What I'm gathering is that at the moment we're still single threaded, but because of libevent, we never have to worry about managing non-blocking -- calls to eventbuffer_write never block, and dbmail_imap_session_set_callbacks sets up the imap parsing as a callback when data is available, with an imap session associated as an opaque handle on each socket. Am I reading right? This looks really good so far.
If I can get my hands on some time, it'd be fun to tack the monitoring back on not as a thread, but as another file handle in the event loop. I wonder if libevent knows how to mix and match unix domain sockets with tcp sockets. It'd be neat to turn /var/run/dbmail-<service>.state into a socket that outputs the state of all imap sessions when it is read. Aaron On Fri, 2008-02-15 at 10:21 +0100, Paul J Stevens wrote: > Hi all, > > Just sending another little update since I merged the events branch into HEAD > late last night and is on track for 2.3.3. > > Apart from being event-driven, I've also refactored the imap code to be much > better at imap compliance. The imaptest tool (imapwiki.org) now passes all > tests > except checkpointing. > > This means that the whole server code has undergone some quite massively > invasive changes. As I explained earlier, the HEAD code now uses a single > process and a single database connector per daemon to handle /all/ incoming > clients. Finally, I've begun putting in some infrastructure for a simple > global > (query) cache that may one day start talking to a memcache backend like we've > been discussing for ages. > > Though performance is quite nice (and already way beyond 2.2) in most > lab-bases > scenarios, this approach has also introduced some very obvious scalability > limitations by design: > > - a single process is doesn't scale in multi-core systems > - a single database connector doesn't scale in case of longer running queries > like complex searches. > > Especially the second limitation will need to be addressed before 2.4. > > Still, dispite these limitations I'm exctatic about the state of things. The > clutter in the servercode is gone leaving a thin and easily maintainable > layer. > And libevent is truly a rock solid layer for driving network IO; I love it! > > > later, > _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
