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

Reply via email to