This is a SyntaxWarning in Python 2.3 and will be an error in 2.4.

all of ZEO from dependencies on this stealth built-in, except for some
non-unit tests).

other modules living in the same package.  It turns out that that
doesn't work when the __import__ builtin has been replaced by one
written in Python.  The easiest fix is to use absolute imports.

recv() call too, else there'd still be a race condition (two threads
both receiving some data, and then the last to read processing it
first, which would be a disaster).

read_index(); with file.name, in FileIterator.__init__().  The latter
one found by pychecker; the former by grepping for FileStorageError.

be arbitrarily long.

buffer variables here are accessed from multiple threads without any
locking@  Add such locking: a separate lock for input and one for
output.  XXX Note: handle_read() keeps the lock for a potentially long
time.  But this is required to serialize incoming calls anyway.

Unrelated nicety: use short_repr() when logging message output, for
consistency with other places.

1) An option to add the thread name to the label.  This is very handy
   during heavy debugging, but also very expensive (two extra function
   calls and some string formatting), so it is off by default; you
   have to edit this file to enable it.

2) In short_repr(), for strings, show the string quote after the three
   trailing dots.

None/1 thingies.  Also explain how state and msg_size interact.

work previously, but the combination of wait=1 and fallback mode now
works correctly -- it waits until connected.)

This prevents spurious ClientDisconnected exceptions.

No jokes about sharing pickles please. :-)

is *not* thread-safe.  So don't share the Pickler.

says it should be cPickle.dumps(), so do that.

asyncore.poll() with a timeout of 10 seconds.  Change this to a
variable timeout starting at 1 msec and doubling until 1 second.

While debugging Win2k crashes in the check4ExtStorageThread test from
ZODB/tests/MTStorage.py, Tim noticed that there were frequent 10
second gaps in the log file where *nothing* happens.  These were caused
by the following scenario.

Suppose a ZEO client process has two threads using the same connection
to the ZEO server, and there's no asyncore loop active.  T1 makes a
synchronous call, and enters the wait() function.  Then T2 makes
another synchronous call, and enters the wait() function.  At this
point, both are blocked in the select() call in asyncore.poll(), with
a timeout of 10 seconds (in the old version).  Now the replies for
both calls arrive.  Say T1 wakes up.  The handle_read() method in
smac.py calls self.recv(8096), so it gets both replies in its buffer,
decodes both, and calls self.message_input() for both, which sticks
both replies in the self.replies dict.  Now T1 finds its response, its
wait() call returns with it.  But T2 is still stuck in
asyncore.poll(): its select() call never woke up, and has to "sit out"
the whole timeout of 10 seconds.  (Good thing I added timeouts to
everything!  Or perhaps not, since it masked the problem.)

One other condition must be satisfied before this becomes a disaster:
T2 must have started a transaction, and all other threads must be
waiting to start another transaction.  This is what I saw in the log.
(Hmm, maybe a message should be logged when a thread is waiting to
start a transaction this way.)

In a real Zope application, this won't happen, because there's a
centralized asyncore loop in a separate thread (probably the client's
main thread) and the various threads would be waiting on the condition
variable; whenever a reply is inserted in the replies dict, all
threads are notified.  But in the test suite there's no asyncore loop,
and I don't feel like adding one.  So the exponential backoff seems
the easiest "solution".

'x' event for a wrapper and then close it.

rid of the silly "smac" word.

logged with the message_output.

importing __builtin__, rather than using __main__.__builtins__.

in load_class().  Found by pychecker.

be too long, but breaking these at an arbitrary character looks wrong
(and can occasionally prevent you from finding a search string).

initialized from the StorageServer's read_only attribute, and later if
the client registers in read_only mode, it may be set even if was off
initially.  This attribute is tested by all write-ish operations.

simple read-only tests.  (These tests pass.)

StorageServer as well as that of the storage itself.  Currently the
test fails.

start_zeo_server() has changed dramatically.)

Don't catch a specific set of errors, catch anything, log the message
that failed, and re-raise the exception.

Eliminate unused class variable VERSION and unused import of struct.

If an exception occurs while decoding a message, there is really
nothing the server can do to recover.  If the message was a
synchronous call, the client will wait for ever for the reply.  The
server can't send the reply, because it couldn't unpickle the message
id.  Instead of trying to recover, just let the exception propogate up
to asyncore where the connection will be closed.

As a result, eliminate DecodingError and special case in
handle_error() that handled flags == None.

instead.

return_error(): be more careful calling repr() on err_value.

which tests a particular combination of packing and transactional undo
at the ZODB layer.

FileStorage/Berkeley storage definition, and undoInfo(), and the
storage interface definition.

This is no longer an invariant.  Storage methods like restore(),
abortVersion(), and commitVersion() can result in a serialno that does
not match the transaction id.

Rather than blaming window for reporting success as an error, the
else clause on the second try block should be an except clause.

ZODB/Connection.py -- the Connection class has a sync() method which
calls the sync() method on the storage if it exists.

- Change pending() to use select.select() instead of select.poll(), so
  it'll work on Windows.

- Clarify comment to say that only Exceptions are propagated.

- Change some private variables to public (everything else is public).

- Remove XXX comment about logging at INFO level (we already do that
  now :-).