each time round the loop (with a 30 sec. timeout).

should fix the problem that messages from different processes or
threads could be intermingled.  The code was rewritten to build up the
lines of the error message in a list which is joined by "\n"
characters at the end.

values that connect_ex() may return when we're connected).  This seems
to resolve the last hangs observed on Win2K.  There are still
(unrelated) hangs on Win98 though.

read-write connection is not available.  This refactors
ClientStorage.notifyConnected() into two functions, testConnection()
and notifyConnected().  testConnection creates the RPC stub and calls
the register() method; it returns the stub plus a flag indicating
whether this connection was preferred or sub-optimal.  If the
register() method raises ReadOnlyError, and the new option
read_only_fallback was true on the ClientStorage constructor, it is
retried with its read_only argument set to 1, and the stub is returned
with the sub-optimal flag.  notifyConnected() now receives the stub
returned by testConnection(), and starts the verification as before.

XXX The read_only_fallback  feature is not yet tested.

XXX More work is needed; when a suboptimal connection is used, the
ConnectThread must stay around trying to get a preferred connection,
and then it must switch connections on the ClientStorage (how???).

different classes that both define a register() method, with different
signatures.  Rename StorageServer.register() to
register_connection().  Also rename its newConnection() method to
new_connection(), for naming consistency.

more understandable.

Got rid of the Connected() exception -- connect(), now renamed to
try_connect(), returns a 1/0 result instead of raising Connected() to
indicate success.

in reST.  I'm not going to figure out how to turn this into a reST
table.

the client.

Also, simplify the test for exceptions received by the client.  If the
class is a subclass of Exception, there's no need to ask if the
instance is of type ClassType.

Increase the timeout from 10 to 30 seconds and add a message to the
failIf() call.

lock.  The lock is now never held for a long time, only while
self.thread is being assigned or inspected, and while a thread is
being created, started or stopped.  Waiting for an event or joining a
thread is now done without holding the lock.  There is no longer a
fear of AttributeError.

When a thread join doesn't succeed within 30 seconds, a message is
logged, and depending on the situation, the join is retried.

The old code would avoid hosing the system when the first jar failed
during its finish.  The logic is that the failure means that
transaction did not commit, so it was safe for all the other jars to
abort.  There are counter-examples to this assumption.  For example,
ZEO could fail after commiting the transaction on the server but
before communicating that success to the client.  It would lead to
inconsistency if the other jars aborted after the first committed.

The solution is to reduce the special case yet further:  If a
single-jar transaction fails during the finish, assume the transaction
is aborted and avoid hosage.  If the jar actually committed, it's
possible to get back to a consistent state since only one jar was
involved.

The effect of this change will be to cause transactions to fail
immediately, rather than the first time they call store() or
abortVersion() or some other write-method.  Since the Connection now
treats empty transactions as a special case, this change will not
change the class of transactions that fail.

parenthesis.

test suite.  The address is now found as the _addr attribute of the
client storage instance.

the BuddyCacheSimulation constructor to round up the cachelimit so
that it reports the actual value used.

to print some information.  Use -s to print size histograms.  This is
pretty raw.  It prints two tables: one for writes, one for loads.

keeping track of the beginning and end address of all free blocks, to
make merging of adjacent blocks a breeze.  The free list is no longer
kept sorted order.

Unfortunately, this still performs poorly.  It has a higher hit rate
(with the 38 minute trace I'm using; the longer traces take too long)
than the buddy system allocator with the same arena size, it is *much*
slower, the memory usage is under 20% (!!!), and despite a roving
pointer, the allocation loop is taken an average of 692 times per
allocation.  At the end of the simulation the free list contains 1039
blocks; I presume this is a steady state approximating the average
behavior.  (There are 2280 allocated blocks at that point, roughly
confirming Knuth's "50% rule" and suggesting that the block merge code
works properly.)

I guess the next idea is separate free lists per size.

tpc_begin(): Get rid of the apply() call since I believe we can now
rely on extended-call syntax being available.

simple free list using a mix of exact-fit and last-fit with a roving
pointer as suggested by Tim.  Use -f to use this version.

Renamed BuddyNode to BlockNode since it is now used by both allocators.

Moved some code around in an attempt to organize it more top-down.

Moved the report printing into the Simulation base class.  Print the
class name and exact cache size before the header; skip the final
report printing if only one previous report was printed.

  Versions:   0 records used a version

1000*1000.  This makes it easier to specify cache sizes for the buddy
system that don't have to be rounded up to the next power of two.  It
does make future reported results incompatible with past results.

allocator.

Different versions of ZODB do different things with the serialnos for
abortVersion().  To be safe and avoid giving non-version data with an
invalid serialno after an abort version, invalidate the version and
non-version data.

This hurts cache effectiveness when a version is aborted, but I expect
it will have little practical impact.