On 25. feb.. 2008, at 09.42, Paul J Stevens wrote:
- finally, start doing the command processing in threads so the
database calls don't block the main thread anymore.
Yes, in a single threaded non-blocking i/o server, you must conduct database operations in a thread to avoid halting the server. The trick though is to do mostly CPU bound operations in the database thread and leave i/o bound operations to the libevent main thread. That way, it is possible to have a few threads in a pool handling many connections. But I guess you know that. I just completed a HTTP application server that does just that for HTTP requests/responses with database access, and I'm also using libevent and of course zdb. This architecture scales very well.
I expect and hope that by combining libevent and libzdb we'll achieve quite an interesting potential for scaling up the imap server. Both represent very exciting technologies that fit very well with what I'm trying to do.
After the above milestones have been completed, and if sponsoring is found we might even add multiple connection pools in the mix so different imap users are mapped to different database backends.
Good catch, I was about to suggest that. Its not obvious that it is possible to use several Connection Pool instances against different database back ends.
Good luck with the project!