[ZODB-Dev] BTrees did it, was: conflict resolution for PersistentList

[Tim Peters]

[Diez B. Roggisch]
>> ok, I tried the btrees, and they seem to do what I want. Gotta figure
>> out how to create nice keys, but thats a minor problem.

[Thomas Guettler]
> I use time.time() (which returns a float on linux) in an application,

It returns a float on all Python platforms, but the resolution varies
greatly.  On Linux time.time() generally has microsecond resolution, but on
Windows it generally updates only 18.2 times per second (resolution of about
0.055 seconds -- don't ask <wink>).

A potential problem is that time.time() can appear to "go backwards" from
time to time, for a variety of platform-specific reasons.  ZODB has a
C-coded TimeStamp type to help with its own need to generate monotonically
increasing transaction ids.  Unfortunately, I don't know of any docs for it,
and the C code is inscrutable (lots of magical arithmetic but no comments).
How to *use* it can be gleaned from ZEO/ClientStorage.py's get_timestamp()
function.  Short course is that basically encodes time.gmtime() in an 8-byte
string, but if the result of that compares <= to the last timestamp you
generated, it boosts the result until > holds.

Then again, all in all, it doesn't really appear simpler than boosting a
global int counter by 1.  In a modern Python, the latter can be done in a
threadsafe way without explicit locking, via, e.g.,

get_next_id = iter(xrange(sys.maxint)).next

Then each invocation of get_next_id() returns a unique integer, starting
with 0.  It inherits thread-safety from the global interpreter lock (only
one thread at a time can execute the bound "next" method, so no two threads
will see the same result).  Alas, if you generate more than sys.maxint+1
ints, it silently overflows and starts delivering negative ints.