Interpreter scheduler and Child interpreters

[Bart Wiegmans]

Hi Jonathan,

Thank you for your response, let me get into the current state of
things as I see it, so as to keep you all updated.

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).

The other way to fix this problem is to simply 'bubble' down the
scheduler object from the parent upon construction. This is cheaper at
runtime and it is a smaller fix (yay!). However, it only works when
the pointer isn't regularly replaced (for instance, by a copying
garbage collector). Nor is it perhaps a very good idea if the garbage
collector implementation of a child interpreter starts walking from
its' parents' scheduler object. Especially if it is in fact a copying
collector.

The Current Problem, however, is that of destruction. Child
interpreters cannot be destructed properly because of a bug in the
garbage collecting subsystem (gc_gms), specifically upon access of the
gc_private variable, which doesn't seem to be initialized properly on
a child interpreters (Note: it seems that way. I base this upon the
fact that after inspection, the last values of the struct are all a
very high and equal value, as if uninitalized).. But I do not know why
that is so.  Initialization of this structure has a special case for
child interpreters; removing this special case does not resolve the
bug.

Kind regards,
Bart Wiegmans


2012/8/7 Jonathan "Duke" Leto <jonathan at leto.net>:
> Howdy Bart,
>
> I like the spirit of this branch. I think what you are trying to do
> should be possible.
>
> It used to be the case that successively created new interps had to
> have the first ever created interp as a parent, but I believe
> whiteknight++ removed that restriction recently. Some docs might still
> indicate otherwise.
>
> I did something similar to what you are doing in PL/Parrot, but I only
> created 2 interps and never had them running at the same time, nor was
> I using the scheduler, so I didn't run into these issues.
>
> Also, while adding the the function Parrot_interp_get_scheduler seems
> cleaner, we may want to make that a macro if it incurs a large
> performance hit.
>
> I hope this helps a bit. Please feel free to barrage us with more questions.
>
> Duke
>
>
> On Sun, Aug 5, 2012 at 2:27 AM, Bart Wiegmans <bartwiegmans at gmail.com> wrote:
>> Hi everybody!
>>
>> Once again, working on mod_parrot, I noticed a bit of an issue with
>> parrot. But I can't really get to how to resolve it, so I'm asking
>> your advice.
>>
>> The context: I want to run multiple interpreters in the same program,
>> at the same time, running different programs. This is a requirement
>> because otherwise, mod_parrot can only run in the prefork apache mpm,
>> which uses a relatively large amount of memory and other resources and
>> for this reason is not very popular with web hosters. Thus, without
>> running in a multi-threaded enviroment, mod_parrot is nearly useless.
>>
>> This is not as simple as it seems, because of the following:
>> * having two separate interpreters at the same time is apparantly not
>> very ok, unless they are parent and child (no idea why)
>> * but if a child is instantiated it does not get a scheduler of its
>> own (Parrot_cx_init_scheduler)
>> * which causes it to crash when starting execution because
>> interp->scheduler is 0x0 (literally everywhere in src/scheduler.c)
>>
>> Thus, I created a new function in src/interp/api.c, called
>> Parrot_interp_get_scheduler, and combed through the code to replace
>> direct access of the scheduler with this delegated access. However,
>> considering the amount of places that it was directly accessed, and
>> seeing the behavior of it, I'm actually doubting whether it is a good
>> idea. I in fact doubt whether having multiple interpreters is a good
>> idea at all given the current state of things. For this reason I'm not
>> placing a pull request right now, but I do ask you to review the
>> changes in the branch, please see
>> https://github.com/bdw/parrot/tree/find-root-scheduler .
>>
>> Kind regards,
>> Bart Wiegmans
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
>
> --
> Jonathan "Duke" Leto <jonathan at leto.net>
> Leto Labs LLC http://labs.leto.net
> 209.691.DUKE http://dukeleto.pl