The stupid question is the question not asked | |
PerlMonks |
Re: Unique filenames with Time::HiRes (looks ok here)by grinder (Bishop) |
on Jul 19, 2004 at 08:16 UTC ( [id://375483]=note: print w/replies, xml ) | Need Help?? |
...NOT very unique... That's very odd. I just downloaded your code (which contains a couple of syntax errors. You need Time::Hires qw/gettimeofday/ (Missing the qw) and there's one too many opening parens in your for loop.
So there's something broken with the installation of your copy of Time::Hires. Can you reinstall it and make sure the test suite passes? Hmmmm.... Unless your machine is so rapid that it just happens to make those calls that quickly. That's within the realm of the possible. What happens if you extend your loop to open files and write to them?
When I run the above, I see a noticeable slowdown, and thus distance, in the names of the files:
If all this fails, you shall have to use a database. Create a table with two columns, a serial number and a cookie. The serial number is managed by the database and gives you a monotonically increasing sequence. The cookie is just a large random string. Collect a number of elements, such as rand(), the time of day, your pid and so on. Hash it with MD5 and insert it into the cookie column. Commit the insert, and then go back and read off the serial number, that's your filename. You can periodically purge the table of all rows. This frees up space and will prevent an already negligeable possibility of duplicate keys from occurring. I still have a nagging suspicion, though, that when you have an arbitrary number of processes generating worksets that have to be processed downstream in sequence, that you cannot absolutely be certain that they will always be in sequence. It seems to me that there's a race issue involved. - another intruder with the mooring of the heat of the Perl
In Section
Seekers of Perl Wisdom
|
|