Hi Matthew,
On Wed, 2009-11-18 at 14:07 -0500, Matthew Barnes wrote:
> With work on Bonobo removal wrapping up, I've finally started taking a
> closer look at Camel (Evolution's mail storage and networking library)
Ah - another life-time of cleaning up, and polishing code: the goal
sounds really nice.
> This is a distant future goal and will have to happen gradually, but I
> would like Camel to shift to a single-threaded design where all file and
> network operations directly use or are derived from GIO's asynchronous
> file and stream APIs.
Hmm; you really propose to remove all threading from camel's
implementation ? or just from it's API ? a full removal might be
problematic.
While clearly threading, if done in an un-constrained way, has it's own
peculiar problems - there are a couple of obvious advantages:
First debugging - while both async and threaded programming loose
determinism due to event re-ordering - the debugger at least understands
threads - and can hopefully show you your state in a reasonably
follow-able way - you can step through slow/blocking calls with 'next',
'finish' etc.; I worry about a world packed with highly granular
asynchronous state-machines, all chained together - with no good way to
see what is happening, what state everything is in, and (of course) why
the app is serenely inactive in it's mainloop suddenly ;-)
Secondly - of course, a fully async mode potentially would loose any
(possible) benefit of parallelism that in theory threads can provide -
in this world of dual-core laptop CPUs, and even hyper-threaded Atoms.
OTOH - I'm sure you know what you're doing ;-)
ATB,
Michael.
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
