[tahoe-dev] Observations on Tahoe performance

[James A. Donald]

On Wed, Aug 26, 2009 at 05:00:24PM -0700, Brian Warner wrote:
> I think it's another example of asynchronous interfaces being such a
> different approach that they really want all the code around them to be
> async too. It's awfully hard to mix sync and async code in the same
> program, and most programs are synchronous, so the async fileio code has
> a tough time getting acceptance, so it never really gets improved/fixed/etc.

All UI intensive programs are primarily asynchronous.  Most programs 
that I write are asynchronous.

Thus an asynch file API needs to be part of a user interface API.  What 
seems to be happening is that one has one implementation of asynch for 
files, and a different, and much better implementation of asynch for 
user interface, and the two implementations are entirely incompatible.

> I thought it was mostly a kernel complexity issue; filesystem code tends
> to rely on the process's kernel stack to keep track of how its getting
> on and when things go async you have to start dynamically allocating the
> stack--this gets fiddly.  I think this is what was going on a few years
> ago in Linux when I last looked at it, maybe things have moved on now?

The correct architecture is that a thread that does asynch has to be 
written around a message pump and message queue, and you keep track of 
how you are getting on by piling up messages in the message queue.  We 
have, over the course of writing UI intensive programs, gathered a lot 
of experience in writing asynch code.

There is a right way and a wrong way to do it.  The right way is:

An asynch program consists of a great pile of event handlers which get 
called by a message queue processor and a message cracker.

If written in C++, an asynch program should inherent from a bunch of 
standard utility programs which implement message crackers, and then 
derive new methods for each of these messages, thus the declaration 
should look like:

class the_app:
	public library_message_queue_and_pump<the_app>
	public library_bunch_of_message_crackers<the_app>,
	public library_more_message_crackers<the_app>,
	public utilities<the_app>,
	public more_utilities<the_app>
	{	/*long list of message handlers derived*/
		/* from methods in the libraries*/
		....
	};

If the asynch file IO code is not used in this fashion, or its pythonic 
equivalent, then it is not done right.