in reply to Localizing Filehandles

Don't ever try this if you play with threads in 5.005. I had a sub that needed to be run many times in parallel: 
sub foo {
    my ($file, $info) = @_;
    local *FH;
    open (FH, ">" . $file) or die "$!\n";
    print FH $info;
    close FH;
    }

[download]
Aparrently perl wasn't too happy with 4 seperate threads copying and writing to the same typeglob, and dumped core to show its' appreciation for the operation :-) I'm glad that  my FH is legit in perl 5.6, although i haven't played with the new threading implementation yet...

Replies are listed 'Best First'.
RE: RE: Localizing Filehandles
by Adam (Vicar) on Jul 15, 2000 at 01:19 UTC
    Interesting. I'll have to watch for that. Although I suspect that it had more to do with perl threads not being fully stable and less to with different threads writing to the same filehandle, since they shouldn't be able to see each other's local typeglobs (they should be out of scope).
[reply]
      The way my boss explained it to me was that local copies the global typeglob, grabs it for local use, and replaces it with a copy of what it grabbed. Thus, any read/write is done on the global FH, even though it is being used in a local scope. The next thread does the same thing, although it copies the typeglob that's being locally used by the first thread (it _is_ still the global one, it's just not being treated as such by the thread). So when the second thread grabs local *FH, it's not grabbing a clean undef typeglob. It's actually grabbing a copy of the typeglob that thread 1 is currently working with, with whatever I/O garbage thread one had in the FH at that particular time. Which is why local sucks in general, and why my rocks my world.

      Disclaimer:At least this is what i think he said.Most people that can detail the changes that occured in the low level file handling structure of perl when 3.0 was released tend to explain things in depths that this PH can't always understand:-)

      BlueLines
[reply]
[d/l]
[select]
        Ah, yes, you are right... local acts on global variables. To paraphrase Sriram Srinivasan (Author of Advanced Perl Programming), local takes the value and stores it elsewhere until the end of the block when it restores the previous value. This would most definately cause a problem with any threaded design since the file handle is global - and available to all threads. I would guess that then that the only reason your script didn't core dump sooner was pure luck (or lack there of, really). Thanks for pointing this out.
[reply]

In Section Meditations