Re^3: How do I get a unique Perl Interpreter ID?

Why do you think some interpreter ID (if such a thing did exist) would be fundamentally better from a randomness/predictability perspective than time+rand, or something similar?

Do you actually need cryptographically secure randomness, or simply distinctness (as one might have inferred from your OP)? A simple counter (like a sequence in a DB) would be producing distinct values, although they're essentially 100% predictable. And as time is like a counter - automatically incremented externally of your program - it doesn't seem like a bad choice in case distinctness is all that you need (and if you're worried about being returned the same microsecond, just wait until it has advanced...)

Comment on Re^3: How do I get a unique Perl Interpreter ID?

Replies are listed 'Best First'.
Re^4: How do I get a unique Perl Interpreter ID? by wrog (Friar) on Dec 01, 2011 at 12:16 UTC
no, you had it right the first time: The interpreter ID is for distinctness, not randomness/unpredictability. (again, I'm using a counter; totally predictable) The point is to have each process/thread independently generating a sequence of keys that are then used to write into a shared cache and life will be a lot easier if I can just know up front that each process/thread has its own namespace and they're just not going to be clobbering each other, in spite of the fact that they are all running the exact same code. ... if I have to be checking the cache first in order to make sure there isn't a value already written there at that key I'm about to use, and also having to do some kind of locking to make sure nobody else is slipping in a write to that key between the check and when I do my own write, etc... that's going to massively slows things down, not to mention being much harder to get right. Where randomness is needed is not for the keys but for the values that are being written, which are indeed supposed to be secret/unpredictable/etc... and in particular it's essential that the values being produced on one thread provide no clue as to what values might be being produced on another thread, and so we again need distinctness in the seeding...	[reply]

Replies are listed 'Best First'.

Re^4: How do I get a unique Perl Interpreter ID?
by wrog (Friar) on Dec 01, 2011 at 12:16 UTC

The interpreter ID is for distinctness, not randomness/unpredictability. (again, I'm using a counter; totally predictable)

The point is to have each process/thread independently generating a sequence of keys that are then used to write into a shared cache and life will be a lot easier if I can just know up front that each process/thread has its own namespace and they're just not going to be clobbering each other, in spite of the fact that they are all running the exact same code.

... if I have to be checking the cache first in order to make sure there isn't a value already written there at that key I'm about to use, and also having to do some kind of locking to make sure nobody else is slipping in a write to that key between the check and when I do my own write, etc... that's going to massively slows things down, not to mention being much harder to get right.

Where randomness is needed is not for the keys but for the values that are being written, which are indeed supposed to be secret/unpredictable/etc... and in particular it's essential that the values being produced on one thread provide no clue as to what values might be being produced on another thread, and so we again need distinctness in the seeding...

[reply]