good chemistry is complicated,
and a little bit messy -LW
How do I get a unique Perl Interpreter ID?by wrog (Pilgrim)
|on Dec 01, 2011 at 03:18 UTC||Need Help??|
wrog has asked for the
wisdom of the Perl Monks concerning the following question:
I.e., not a process ID, or a thread ID, but an Interpreter ID.
As I understand it (from my reading of perlguts/etc), whenvever a new interpreter is created or cloned, there's a whole structure created that contains interpreter-specific stuff, and it seems to me there ought to be something in there that is unique to that interpreter instance and easy to get at....
... and perhaps even accessible from pure Perl (is there a magic variable I've overlooked?)
To be sure, I imagine I could write an XS function that, say, takes the address of PL_modglobal or Perl_get_context(), returns it as an integer and use that to distinguish my interpreters, but
. . . . .
For the curious, here's the problem I'm actually trying to solve, for which being able to get at an Interpreter ID seems the obvious, easy answer at the moment:
Consider a script that is running possibly in multiple processes and/or multiple threads at the same time (think mod_perl on MPM-Worker, but I don't want to limit myself to that particular situation).
The script needs to contain a counter method, e.g.,
the idea being that every invocation of this method must return a distinct result, no matter which process or thread the invocation occurs on. (Why do I need this? Cryptography.)
It's also important to be able to do this without having to consult any kind of shared cache.
So what's the minimal data other_initialization_stuff() can be returning so that this is actually the case? Bonus points if it's something that's guaranteed to work on all OS's (though I'm happy enough if I can cover Linux and Win32).
Including $$ distinguishes different processes (**) (***); so it's really about how to deal with multiple interpreters in the same process.
Note that Thread ID does not help us because in some cases (e.g., mod_perl) there is not a fixed correspondence between threads and interpreters -- we cannot rule out multiple interpreters getting (consecutively) loaded into the same thread to run the counter initialization code.
My theory in this is that there will be a one-to-one correspondence between interpreter IDs and the distinct instances of @values within a given process, which is what I want.