I'm considering a one line addition to the threads module to overload the string value of a thread to return its ID: 
  '""' => \&tid

[download]
Since thread IDs are unique, thread objects could be used as hash keys in a more rational way: 
  $timeouts{$thr} = $secs;

[download]
Also, it would also simply such things as: 
  print("Thread $thr running...\n");

[download]
While this is not completely backward compatible, I'm wondering if that really matters. For example, according to CPANTS there are no CPAN modules that have 'threads' as a requirement other than 'thread::shared', 'Thread::Suspend' and 'Thread::Cancel', and I know they won't break.

As to other user code out in the Perl universe, the only code that would break would be cases where the current stringified version of a thread (i.e., 'threads=SCALAR(0x...)') is explicitly tested for. IMHO, I think that such a case would be extremely rare, and as such, would not justify blocking the proposed change.

Comments?

Remember: There's always one more bug.

Replies are listed 'Best First'.
Re: [RFC] Stringifying a thread
by diotalevi (Canon) on Oct 04, 2006 at 20:56 UTC

    How about using the original stringification plus the thread id? Make numification use the thread id instead.

    use overload '""' => \&as_string, '0+' => \&as_number;

sub as_string {
    # Foo::Bar=HASH(0xDEADBEEF),tid=42

    my $self = shift @_;
    return overload::StrVal( $self ) . ',tid=' . $self->tid;
}

sub as_number {
    return shift->tid;
}

    [download]

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]
Re: [RFC] Stringifying a thread
by BrowserUk (Patriarch) on Oct 04, 2006 at 21:16 UTC

    I think this is a great idea--and definitely the stringified => tid not the numified.

    Extremely useful for adding to error and trace messages, where you currently have to use <c>printf "... %d ...", threads->tid.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re: [RFC] Stringifying a thread
by ambrus (Abbot) on Oct 05, 2006 at 16:36 UTC
    For example, according to CPANTS there are no CPAN modules that have 'threads' as a requirement other than 'thread::shared', 'Thread::Suspend' and 'Thread::Cancel', and I know they won't break.

    That's probably because threads is a core module (for perl versions that support it) so some people don't bother to specify it as a dependency explicitly.

[reply]
Re: [RFC] Stringifying a thread
by samtregar (Abbot) on Oct 05, 2006 at 17:56 UTC
    I hate this in Class::DBI. I've gone down many a fruitless debuging path trying to figure out why a variable that was supposed to have an object in it for some reason ended up with a number.

    Things should look like what they are when you print them. You might be able to satisfy your need for a better hash-key and better debugging statements by stringifying to "THREAD OBJECT (ID $id)" or something similarly unmistakable.

    -sam

[reply]
Re: [RFC] Stringifying a thread
by ysth (Canon) on Oct 06, 2006 at 10:01 UTC
    I'm not sure it's worth it. The two drawbacks I see are the increased memory use from loading overload.pm (not sure if this applies or not if you use the newish XS support for overloading) and the slight performance hit on almost every opcode when there is any use of overloading (this no longer applies in bleadperl where performance is lowered whether or not you use overload).

    These aren't really strong reasons against it, but I'm not sure your reasons for it are any stronger.

[reply]
      '==' is alreadly overloaded for threads, therefore overload.pm is already loaded. As a result, adding ""-overloading doesn't cost anything extra.

      As to performance, my tests show that overloading only costs a few percent. However, generating a 'default' string from an object (e.g. 'threads=SCALAR(0xABCDABCD)') is HUGELY expensive. Therefore, I found that for ops like "... $thr ..." and $hash{$thr} there is a greater than 500% speed improvement overall with ""-overloading.

      However, while the performance increase is really nice, I like the usabily aspects more.

      Remember: There's always one more bug.
[reply]

        It's not like most of the calls in threads are generally high frequency calls.

        create and async have to spawn a new interpreter and clone god know's what.join has to wait for a thread to finish and an interpreter to be cleaned up. Not much else is performance criticla either.

        Even in the 'spawn and discard' model of server application, there are at least two IO operations which would totally swamp any overload overhead.

        If the overloading had a detrimental affect upon some of the calls in threads::shared, like lock or cond_signal, that might be noteworthy, but presumably that is not the case?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        '==' is alreadly overloaded for threads, therefore overload.pm is already loaded. As a result, adding ""-overloading doesn't cost anything extra.
        Then you can disregard everything I said, except that you may want to switch to using the XS OVERLOAD: keyword.
[reply]

Back to Meditations