--- Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> >>>>> "SWM" == Steven W McDougall <[EMAIL PROTECTED]>
> writes:
>
> SWM> If you actually compile a Perl program, like
>
> SWM> $a = $b
>
> SWM> and then look at the op tree, you won't find the
> symbol "$b", or "b"
> SWM> anywhere in it. The fetch() op does not have the
> name of the variable
> SWM> $b; rather, it holds a pointer to the value for $b.
>
> Where did you get this idea from? P5 currently does many
> lookups for
> names. All globals. Lexicals live elsewhere.
Globals whose names can be resolved at compile time are,
with the SV* is stuck in to o->op_sv.
> SWM> If each thread is to have its own value for $b, then
> the fetch() op
> SWM> can't hold a pointer to *the* value. Instead, it
> must hold a pointer
> SWM> to a map that indexes from thread ID to the value of
> $b for that
> SWM> thread. Thread IDs tend to be sparse, so the map
> can't be implemented
> SWM> as an array. It will have to be a hash, or a
> B*-tree, or a balanced
> SWM> B-tree, or the like.
Or, say a hash table by pointer value that only contains
thread-local-ified globals - the rest juat use the stored
pointer (So for only a few thread-local globals, there is
very little overhead). I.e.
OP* PERL_FASTCALL p6_pp_fetch (perl_thread *t)
{
SV *real_sv = ((SVOP*)PL_op)->op_sv, tsv;
if (tsv = p6_ptrtbl_fetch(t->t_localsvs, real_sv))
real_sv = tsv;
p6_extend_stack(&t->t_stack, 1);
p6_push(&t->t_stack, real_sv);
}
> Now where
> sub recursive() { my $a :shared; ....; return
> recursive() }
> would put $a or even which $a is meant, is left as an
> excersize
> for someone brighter than me.
%P6-E-MEANINGLESS, "my $a : shared" is a meaningless
construct.
-- BKS
__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
