The current behaviour (where stringifying a thread returns the class
name plus addrress) *IS* used by automatic dumpers. It is also a handy
feature in interactive debuggers since you can immediately tell what
kind of object a pointer is pointing too. If this change is made then
thread objects will be different from every other object class in the
world - and that is a bad thing. Automatic dumpers and tree walkers
will have to add special code for this.
So, yes, this will break some things and make life a bit harder for
debuggers.
Why is the current stringify behavior a problem? The current strings
are perfectly valid hash keys. The phrase "rational hash key" is an
oxymoron - the point of a hash is to randomize things so making the key
more "rational" doesn't do you any good at all.
To be concise, if a human is going to look at the string, then the
current stringification is better. If a machine (i.e., the hash
algorithm) is going to look at the string then it doesn't matter since
both are unique. If you really insist on using the TID for a hash key
then just use $thr->tid().
- Jim
Jerry Hedden wrote:
I'm considering a one line addition to the threads module to overload
the string value of a thread to return its ID:
'""' => sub { shift->tid() }
Since thread IDs are unique, thread objects could be used as hash keys
in a more rational way:
$timeouts{$thr} = $secs;
Also, it would also simply such things as:
print("Thread $thr running...\n");
Comments?
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
