in reply to Re: yet another thread question: is Symbol::gensym threadsafe?
in thread yet another thread question: is Symbol::gensym threadsafe?

return the address of an anonymous glob

I'd be vaguely uncomfortable with the idea that memory could be recycled and at some point you would generate the symbol name more than once.

I would be inclined to extend the symbol name to include the current thread id:

use Config ();

sub gensym () {
    my $id = $Config{useithreads} ? threads->tid . '-' : '';
    my $name = "GEN$t" . $genseq++;
    my $ref = \*{$genpkg . $name};
    delete $$genpkg{$name};
    $ref;
}

[download]

• another intruder with the mooring in the heart of the Perl

Replies are listed 'Best First'.
Re^3: yet another thread question: is Symbol::gensym threadsafe?
by BrowserUk (Patriarch) on Oct 24, 2007 at 15:36 UTC

    But, as the names are immediately deleted from the symbol table each time: 

    delete $$genpkg{$name};

    [download]

    before the reference is returned to the caller, they can never again be referenced by name, so I don't think there is the possibility for confusion there. Hence, as the sequenced names are never used beyond the point of creation, there seems no reason for sequencing them in the first place when local can give us a new, unnamed glob whenever we want one?

    I'm guessing the current implementationis simply a part of history from before local was available--and definitely predating me.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      simply a part of history from before local was available

      No. local predates modules and so also predates the Symbol module.

      The generated name can be output when the file handle is dumped and it is nice to be able to distinguish between two file handles in such debug output. Hence unique names are generated.

      You also appear to have disproven your own argument that the numbers overlapping between threads might cause a problem, especially since your proposed solution to that problem is to eliminate the numbers. :)

      - tye        

[reply]
        The generated name can be output when the file handle is dumped ...

        So, even though the name is deleted from the symbol table, it can still be recovered from somewhere?

        And if it can be recovered from somewhere, then there is the possibility of conflict. Either in where the names are being stored for recovery. Or even in that someone, somewhere may be using those recovered names, assuming them to be unique.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom