Here is one, that need some design decision:
Parrot_base_vtables[] (the master array of all registered vtables) is currently a true global. This causes nice errors and segfaults on i386/JIT, when NCI calls are JITted, because the JITted method call stub is located in that global Parrot_base_vtables[].
(Currently Parrot_base_vtables[] is checked to be set only once and JITted NCI ist disabled).
The question is: Should Parrot_base_vtables[] be a real global or per interpreter? This is of course related to the question, how dynamic do we want to have registered PMCs, that is: Can different threads register different PMCs? Do ParrotClass objects get an entry in that table (currently yes)? The class_hash is per interpreter, so this doesn't play together either.
Trying an answer:
*If* ParrotClasses are per thread (very likely yes - different threads might create different objects of different classes dynamically) *and if* Parrot_class_register() creates entries in Parrot_base_vtables[], then this structure has to be per interpreter too.
This also implies, that we have to lookup dynamically registered PMCs and ParrotClasses per name and not per ID, at least for the general case.
Comments very welcome, leo
