in reply to Re: How do I get a unique Perl Interpreter ID?
in thread How do I get a unique Perl Interpreter ID?

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...

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

Replies are listed 'Best First'.
Re^3: How do I get a unique Perl Interpreter ID?
by afoken (Chancellor) on Dec 02, 2011 at 10:05 UTC
    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).