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.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] String hashing code, Abel Braaksma | Thread | Re: [xsl] String hashing code, Abel Braaksma |
[xsl] [Afwezig] xsl-list Digest 15, roel | Date | [xsl] XPath - excluding specified c, Steven |
Month |