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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--