I definitely want to continue using the pooled thread model for incoming client
connections, which is what we do now, regardless of which protocol is being
spoken. It's well tuned, well tested, and a great performer.
What we're focusing on here is the various tasks where Citadel server wakes
up and "does something" on its own: batching up mailing lists, performing
aggregation tasks, etc.
Event driven is a neat idea. However I think dothebart went too far by trying
to address *every* *single* *place* where an aggregation task might go into
a wait state. I think we should give every major task its own thread, and
we should also find some way to implement a watchdog timer on each of them.
In the past we simply relied on connection timeouts (either directly or through
libcurl). When there was a problem connecting to something it often slowed
the queue down, but it never locked
up completely, which is what's happening now.
I'm also ok with spawning child processes if we can find a way to attach
them to the data store. This would make each task "killable" without any
collateral damage to interactive sessions. It might also eliminate the need
for event-driven jobs. Perhaps we have outgrown the single process paradigm.
