Interpreter scheduler and Child interpreters

Stefan Seifert nine at detonation.org
Wed Aug 8 08:27:45 UTC 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20120808/45475a53/attachment.asc>


More information about the parrot-dev mailing list