Elizabeth Mattijsen <[EMAIL PROTECTED]> writes: >At 12:47 PM 8/10/02 +0200, Arthur Bergman wrote: >>>Ah.. ok... I didn't know that. >>>But at least the value will only be copied to the thread that actually >>>requests it, so that is a saving I would think? >>That is how it works right now, except that it is cloned aswell, I have a >>patch that will defer the cloning of shared values. > >Hmmm... thinking some more about this. Why _is_ the FETCHed value of a >tied variable saved locally?
Partly to save the cost of re-doing FETCH, and partly to make the SV look like any other so that large slabs of core code don't need to know that it is tied - once it is FETCHed it can then be passed around C code like any other SV. >How would any internal (XS) module know >whether it would be ok to use the saved value or to do a FETCH again? There are a whole slew of flag bits that tell C code SV is magical and that FETCH has been done. The particular C code gets to choose how many times it calls FETCH to "do the right thing" - see fairly recent p5p mail for cases where people think FETCH is called to many times > >Would it not make even more sense to change this behaviour of tied variables? For perl6 yes. For perl5 they are so widely used that any change is likely to break something. -- Nick Ing-Simmons http://www.ni-s.u-net.com/
