> I'm currently investigating various issues related to internal > interpreter data structures and multiple threads. > 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. >
>From a PHP perspective, having it per-thread would be a very good thing. If you dl() (PHP's version) an extension it should *only* be available to the execution path that called it. COW would be fine for that - and shouldn't yield too much of a performance decrement. At least that's the PHP 2c. :) -sterling
