I peeked at Data::UUID. I see static variables within functions and I haven't yet spotted any evidence that they're doing any locking to make sure only one thread at a time is calling the functions in question => Big Multithreading Fail (which is fine if one doesn't have to play in that world, but I do, so...)

At this point the question then becomes how you build something like Data::UUID that works in the multithreaded realm. As far as I can tell Data::UUID is relying entirely on clock gymnastics, in which case it's no wonder if they punted on multithreadedness.

Also while universality is nice, I think I'd prefer to not have the IDs longer than they need to be. Something that'd be unique across a single server farm over some fixed interval of time like 100 days is good enough for my purposes. Granted, I'm also not sure how much effort I want to expend on optimizing that particular piece of the puzzle...

I'd prefer to not have the IDs longer than they need to be. Something that'd be unique across a single server farm over some fixed interval of time like 100 days is good enough for my purposes.

When I need unique IDs, I usually have a RDBMS running somewhere that has solved all of the nasty race and locking problems. What if you would simply (ab)use a RBDMS, create a sequence there, and get the sequence's nextval whenever you need an ID?

Or, if you work across several RDBMS, you could concat a server ID (IP address or hostname, if you have no better idea) and a sequence number into a locally unique ID.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

What if you would simply (ab)use a RBDMS, create a sequence there, and get the sequence's nextval whenever you need an ID?

because a call out across the network to a bottlenecked server is exactly the sort of thing I'm trying to avoid (compare with interpreter ID being right there in thread-specific storage).