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

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: yet another thread question: is Symbol::gensym threadsafe? (history)
by tye (Sage) on Oct 24, 2007 at 16:13 UTC
    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]

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

        Yes. 

        >perl -le "my $g = \do{ local *GLORB; *GLORB }; print $g; print *$g"
GLOB(0x225f08)
*main::GLORB

        [download]

        But that's not a problem, or at least not a new one, because the globs created by auto-vivification of lexicals are not uniquely named either. Your hypothicical "someone" doesn't support lexical file handles, so I wouldn't worry about his inability to support threading.

[reply]
[d/l]

In Section Seekers of Perl Wisdom