>>>>> "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.

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.

You are imagining an implementation and then arguing against it.
What about a simple block of reserved data per'stack frame' and the
$b becomes an offset into that area? And then there are all the
other offset for variables that are in outer scopes.

Here is my current 'guess'.

A single pointer to the thread interpreters private data.
A thread stack (either machine or implemented)
A thread private area for evaled code op trees (and Damian specials :-)
A thread private file scope lexical area

The lexical variables would live on the stack in some frame, with outer
scope lexicals directly addressable (I don't recall all of the details
but this is standard compiler stuff, I think the dragon book covers
this in detail)

The shared variables (e.g. main::*) would live in the well protected
global area.

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.

Chaim Frenkel                                        Nonlinear Knowledge, Inc.
[EMAIL PROTECTED]                                               +1-718-236-0183

Reply via email to