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] |
pure luck it was. usually the first thread would complete a read/write cycle, and occasionaly the second thread would as well. However, the third and fourth threads were guaranteed to spill core. I have to say that this is the first time in 2 years i've managed to make a perl program dump core (took me 3 weeks in C ). That definitely says something about our chosen craft......
BlueLines
| [reply] |