Re: String hashing code

Abel Braaksma wrote:
> If you looked carefully, you must've seen it also uses a timestamp.
> Together it should provide uniqueness, both within one run and between
> runs. Unless of course you have a system where all are runs run
> simultaneously in the same microsecond (which is not likely since
> starting a processor alone takes somewhere between 20 and 400 ms).

I didn't see anywhere that specified the minimum precision of the
timestamp in the spec, so knowing my luck I'll encounter the one system
that gives integer-second-level granularity while still being able to
run an XSLT 2.0 processor.

> If the problem you are facing is the possibility of names of files
> already existing, you can combine two methods. One: try the most
> randomizing way of creating a filename, two: use
> unparsed-text-available(...) to check whether a previous run already
> created that file, or better, let it loop with a counter until it finds
> a free "slot" (use the high significant bit of the random number of the
> UID or simply add another counter yourself).

True, though years of multithread programming has taught me a strong
aversion to the inherent race condition in non-atomic test-and-create
operations like this.  It can't possibly be as big a risk as hash
collision, but it doesn't stop me feeling any less dirty.

As always, perfection is impossible, so ultimately it comes down to how
much effort I am willing to go to for that extra nine of reliability.