Subject: Re: [xsl] String hashing code
From: Deborah Pickett <debbiep-list-xsl@xxxxxxxxxx>
Date: Sat, 15 Dec 2007 17:32:50 +1100
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.