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