(Non)shared interpreter data

[Leopold Toetsch]

Hi,

with the arrival of STM and (again) thread support in parrot trunk, we should
ponder various interpreter structures and data regarding their usage with
threads.

E.g. classes, namespaces, bytecode, IO PMCs, and likely more.

Here are my thoughts so far:

1) classes / PMC types

As any thread could create new types on the fly (even in an eval-like manner),
it seems to me, that C<interpreter->class_hash> is distinct per thread. Some
lazy copy feature of already existing classes would probably be desirable.

2) namespaces

Ditto, the more that there are some rumours that class isa namespace.

3) bytecode / subroutines

These shall be shared. *But* there's the problem of per-thread data in
bytecode-related structures. E.g. the PIC structure or
PMC_sub->namespace_hash are per thread, which currently causes some excessive
cloning of subroutines. There's of course also a problem, if a thread does
C<load_bytecode> or "eval".

4) IO

When I'm reading POSIX specs or manpages correctly, then file descriptors are
shared amongst threads. The implementation is then currently wrong as
C<interpreter->piodata> is allocated per interpreter/thread.

Regarding per-thread data in shared structures: a per interpreter array
(indexed by a public key, which is stored in the shared structure) would
help. See also pthread_{s,g}etspecific(3p) and pthread_key_create(3p).

Comments welcome,
leo

[Leopold Toetsch]

Am Donnerstag, 7. September 2006 01:45 schrieben Sie:
> What about continuations? On one hand, they are used for flow control,
> on the second they are data like any other.

As you can't use a Continuation to continue in a different thread or
interpreter, these ought to be really non-shared. If a Continuation would be
passed on to a different thread, it shall be "readonly" (aka non-invocable)
and only usable in the originating interpreter.

leo