On Fri, 2009-11-20 at 10:36 +0000, Michael Meeks wrote: > Hmm; you really propose to remove all threading from camel's > implementation ? or just from it's API ? a full removal might be > problematic.
There may be isolated cases internally to Camel where it can exploit parallelism in CPU-intensive tasks with threading or where threads are necessary for interacting with synchronous-only libraries, but it should be used sparingly and hidden behind a fully asynchronous API. It should not be central to the design of the entire mail application, as it is currently. Basically I want the mail front-end in Evolution 3 to be single threaded, or as close to that as possible. My motivation for the manifesto stems from two sources: The first is what I think is a very insightful paper on the inherent problems with threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf The second is Peter William's design document on Camel, which has been sitting in our source tree for nearly a decade: http://git.gnome.org/cgit/evolution/tree/mail/README.async Setting aside the outdated implementation details he talks about, it's clear that many of Camel's early design decisions that were made during the 1.x era (or perhaps earlier?) are essentially still in place today. Reading through that document now, the rationale just doesn't stand up anymore, in my opinion. CamelObject should have been killed off long ago, and the arrival of GIO and now GNIO totally changes the game for us. Peter even hints at -- as what was then a distant future goal -- basically what I'm proposing now, here in the distant future. Standing on the cusp of a new era for GNOME, I feel like the time is right to reevaluate what's working and what's not and at least -attempt- a course correction. I think an asynchronous design that takes full advantage of our increasingly capable platform libraries is the way forward. I just don't want to spend the duration of GNOME 3 struggling with the same tired old issues that we struggled with for much of GNOME 2. The community's patience is wearing thin and so is mine. Matthew Barnes _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
