On Tue, Oct 24, 2000 at 10:55:29AM -0400, Chaim Frenkel wrote:
> I don't see it.
>
> I would find it extremely akward to allow
>
> thread 1: *foo = \&one_foo;
> thread 2: *foo = \&other_foo;
> [...]
>
> copy the &foo body to a new location.
> replace the old &foo body with an indirection
>
> (I believe this is atomic.)
Actually, that shouldn't be awkward, if both threads have their own
private symbol tables.
In any case, that's a different kind of threading. IPC threading
has nothing to do with bytecode threading (for the most part).
What you describe here is IPC threading. Larry was talking about
bytecode threading. :-)
Bytecode threading is a concept pioneered in Forth ~30 years ago. Forth
compiles incredibly easily into an intermediate representation. That
intermediate representation is executed by a very tight interpreter
(on the order of a few dozen instructions) that eliminates the need for
standard sub calls (push the registers on the stack, push the params
onto the stack and JSR).
Forth works by passing all parameters on the data stack, so there's no
explicit need to do the JSR or save registers. "Function" calls are done
by adding bytecode that simply says "continue here" where "here" is the
current definition of the sub being called. As a result, the current
definition of a function is hard-coded into be the callee when the caller
is compiled. [*]
The problem with
*main::localtime = \&foo;
*foo = \&bar;
when dealing with threaded bytecode is that the threading specifically
eliminates the indirection in the name of speed. Because Perl expects
this kind of re-assignment to be done dynamically, threaded bytecodes
aren't a good fit without accepting a huge bunch of modifications to Perl
behavior as we know it. (Using threaded bytecodes as an intermediate
interpretation also confound optimization, since so little of the
context is saved. Intentionally.)
Hope that clarifies things.
Z.
*: Forth is an interactive development environment of sorts and
the "current definition of a sub" may change over time, but the
previously compiled calling functions won't be updated after the
sub is redefined, unless they're recompiled to use the new definition.
It gets stranger than that if you probe more deeply.
