Front page | perl.ithreads |
Postings from August 2002
From: Nick Ing-Simmons
August 11, 2002 04:55
Message ID: email@example.com
Elizabeth Mattijsen <firstname.lastname@example.org> 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.