Nick Ing-Simmons wrote:
> >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.
Exactly - unshared variables use the non-locking and (hopefully!) faster
variant, wheras shared variables use the locking variant. As you say,
with the correct vtable implementation this should be invisible to the
op and everything above it. I'll confess to an (almost) complete
ignorance of the existing optree/opcode mechanism in perl5 - I know just
about enough to know it is exceedingly complex. I don't therefore feel
qualified to pontificate on how simple this would be to do in practice,
but I'm sure someone with a sufficiently pointy head will :-)
> >- 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.
Agreed. The thought behind this was that if a non-threaded module is
'use'd just within a single thread then no other threads should need to
or in fact be able to see it's optree or its namespace. I think perhaps
some new variant of 'use' is needed to specify that the module should
only be made availble to the current thread (i.e. interpreter instance)
- 'useonce MyMod;' or somesuch, or even a pragma at the top of a module
to explicitly say that it is safe to share a single copy between
multiple threads/interpreters - although how this would actually work
needs careful thought (which I havn't really given it). Perhaps a
possible scheme would be to build a seperate optree for each module as
it is loaded, and for each thread/interpreter to hold a reference to the
ones that it uses. This way the optrees could remain readonly, but
still be shared if required and safe to do so. If no extant threads
refer to the optree, it could perhaps be freed - sort of
reference-counted optrees. I'm winging it a bit here becasue I don't
know if this is a good idea/vaguely possible/barking mad (choose one).
--
Alan Burlison
