Re: [RFC] Stringify a thread

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 
>