Re: [Evolution-hackers] Camel Manifesto
- From: Matthew Barnes <mbarnes redhat com>
- To: michael meeks novell com
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Camel Manifesto
- Date: Fri, 20 Nov 2009 10:46:49 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]