it is in use by another thread.

__init__.  The hang was in the accept() call.  I don't understand
exactly why, but I suspect it was because we were always reusing
the same port when a trigger was closed and another opened right
away.  Fixed this by cycling over ports [19950...19999].

Also cleaned up the code somewhat.

Also changed the loop in close_conn() to go over the dict's values,
since those are all that's used.

following item:

Picklers are not re-entrant!  The only place where the shared global
pickler was used was in the error handling in store(), to test whether
the caught exception can be pickled (else it would fail when sending
the response).  Change the flow control to create a new pickler
locally, only when an exception is caught.  (When no exception is
caught, we know newserial is a string so there's no need to test its
picklability.)

in the docstring that filter should be None.  Also change the return
value if filter!=None from () to [], to match the type of what it
returns in other cases.

methods here.

the server to take the "async=0" path which could cause recursive
calls to message_input() or message_output(), which would hang due to
the input/output locks.

Use the ZEO storage id rather than the ZODB storage name.  The latter
is usually a long path to a file, which is relatively uninteresting.

Also remove unused optional argument 'last' from new_oid() and
'_stuff' from load().

Also rename _startServer() to startServer() for consistency with
shutdownServer().

When the import changed to be absolute rather than relative, the trick
of using the same Python string for the import and the getattr failed.

Add an assert() that TimeStamp is not NULL.

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".