[ZODB-Dev] ZEO packing

[Guido van Rossum]

> On Wednesday 18 Sep 2002 12:44 pm, Toby Dickenson wrote:
> > A few weeks ago Jeremy added SlowMethodThread handling to the ZEO 2
> > StorageServer so that potentially long undo operations dont block other ZEO
> > clients. This is *very* nice.
> >
> > This new mechanism has also been used for handling pack, which has caused a
> > change in behavior that I was not expecting. Previously ZEO clients would
> > see the pack method return immediately, and the ZEO server ran the pack
> > asynchronously. Today the packing will block that ZEO client, the same as
> > if there was no ZEO between the client and the underlying storage.
> >
> > I think this new behaviour is better, but I guess it could cause a problem
> > if you are not expecting it.
> >

[And then he replied to himself]
> Eeek! it looks like this change may have been accidental. In
> ClientStorage.py:
> 
>     def pack(self, t=None, rf=None, wait=0, days=0):
>         ....
> 
> "wait=0" suggest that the default was intended to be not waiting,
> the same as ZEO1, but in StorageServer.py
> 
>     def pack(self, time, wait=None):
>         if wait is not None:
>             ....
> 
> I propose changing StorageServer to check "if wait:" rather than "if
> wait is not None:" so that passing wait=0 has the expected
> effect. Do we want the default to be blocking or non-blocking?

Thanks fot noticing!

The default has always been non-blocking AFAIK, so it should stay
that.

I've fixed StorageServer to use wait=0 as the default and to use "if
wait:" for the test.

I've noticed several places in the ZEO code where boolean variables
used None for false and 1 for true, and some places where "if object
is None" was used as a test.  I don't know where this idiom started,
but I agree it's evil, and should be banned.  "if object is None"
should be used when object has a useful value *or* is left None, but
not for booleans where the intention is true/false.

(One more reason why having an explicit bool type in the language
would have been a good idea from the start.)

--Guido van Rossum (home page: http://www.python.org/~guido/)