It may be worth looking at something like APR (http://apr.apache.org/)
for dealing with things like threads and shared memory on disparate
platforms. No doubt this would bloat dbmail somewhat, but it's always
nice to not have to do it all yourself, as we've seen with gmime.
Paul J Stevens wrote:
Matthew T. O'Connor wrote:
Aaron Stone wrote:
The next big project is multithreading the daemons. Even if that's the
only change that is made, I think it will take a while to get right. Of
course I'm open to different ideas, and I'm researching threading
frameworks that we can leverage to reduce our development time. Anyways,
getting into those details we should move onto the dbmail-dev list.
May I ask why this is important? Threads aren't the end-all-be-all that
lots people think they are. I believe a multi-process system can be
every bit as fast as a threaded server, and it's a lot less complicated.
Using threading is not a goal in itself, but a means.
One of the goals for 2.3+ is adding new imap capabilities like NOTIFY
that require a lot of IPC between running imapd processes. Using threads
will make that quite straightforward.
Another goal is scaling up the number of concurrent connected clients
without depleting the database connections. Using connection pools is a
best practice there, and even though that could be done in a
multi-process architecture, this is generally done using threads.
So yes, imo also there's a very solid case for threads in dbmail. But
like Aaron says, it will take some time to do this right. Neither I nor
Aaron (afaik) have any experience with threads in C so we'll have to
learn how to do it as we go along :-)
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
