On Wednesday 08 August 2012 09:41:07 Bart Wiegmans wrote: > As far as I know, it is still the case that all successively created > interpreters have to be children of the first, and whiteknight++ > explained why. As far as I understand it, there is a global array of > interpreters which only the first interpreter can construct. Thus in > current master, we cannot create interpreters independently. This is a > bug, but one that can be easily worked arround. > > There are a number of reasons that I require all interpreters to have > access to a scheduler, some of which are the requirements of some > opcodes on the presence of the scheduler (notably sleep, which I ran > into recently, and which is really useful to web developers at times), > and that the standard API entry points require a scheduler to start > their task on. (It should be noted that threads, which I haven't > looked into much, does all this very differently).
It's time that I chip into this discussion. In the threads branch I heavily changed clone_interpreter and use child interpreters for child threads. One of the changes is that each child interpreter now has it's own garbage collector and memory pools. Child interpreters now also use proxies to access the parent's gobal data like namespaces, HLL infos and globals. I honestly have no idea if it's still possible to create and run a child interpreter as you seem to try doing. It could be that everything simply still works. But in any case, child interpreters have the same constraints as child threads. Most importantly, child interpreters cannot change the mentioned global data. They have to send a task to the main interpreter to do it for them. They can also only use classes which have been used before on the main interpreter due to some lazy initialization in class.pmc's instantiate VTABLE method. At least this is the way it is when using clone_interpreter to create a new interp. I actually don't know other ways. Stefan
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
