Alan Burlison <[EMAIL PROTECTED]> writes:
>
>Another good reason for having separate interpreter instances for each
>thread is it will allow people to write non-threaded modules that can
>still be safely used inside a threaded program. Let's not forget that
>the overwhelming bulk of CPAN modules will probably never be threaded.
>By loading the unthreaded module inside a 'wrapper' thread in the
>program you can safely use an unthreaded module in a threaded program -
>as far as the module is concerned, the fact that there are multiple
>threads is invisible. This will however require that different threads
>are allowed to have different optrees
Why ?
I assume because you need to use 'special ops' if the variables that
are used happend to be 'shared'?
If so this is one area where I hope the vtable scheme is a clear win:
the 'op' does not need to know what sort of variable it is - it just
calls the vtable entry - variable knows what sort it is and does the
right thing.
The tricky bit i.e. the _design_ - is to separate the op-ness from the
var-ness. I assume that there is something akin to hv_fetch_ent() which
takes a flag to say - by the way this is going to be stored ...
>- perhaps some sort of 'copy on
>write' semantic should be used so that optrees can be shared cheaply for
>the cases where no changes are made to it.
I would really like to keep optrees (bytecode, IR, ...) readonly if
at all possible.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
