parrot-dev Digest, Vol 48, Issue 8

[Bart Wiegmans]

Hi all,

Good to have this discussion!

First of all, the child_interpreters test does in fact work with the
threads branch (up until destruction, again). For the record, the
child-interpreters test simply creates two interpreters, one the child
of the other, runs a script on the first, then the second, and then
destroys the second, and the first interpreter. This all happens in a
single thread, and it is basically the behavior I need at the minimum
if I'd like to keep interpreters arround for longer than a request. As
it sounds right now, the fact that it works may be by accident, but
that is OK by me.

Where all branches so far have crashed is upon the /destruction/ of
the child interpreter. However, without proper destruction, child
interpreters make no sense. Let me explain fully what I'm trying to do
and why, because it may not be obvious:

* first of all, I want mod_parrot to run in multi-threaded servers.
For this, I need to be able to run different scripts / programs on
different interpreters at the same time. I.E. every thread has to have
its own interpreter on which a program runs.
* Secondly, I'd like to separate interpreters into long-lived
'preparatory' or 'loader' interpreters, which run /only/ the loader
script, and short-lived 'user' interpreters, which run the 'user'
scripts. The latter of which /have/ to be destroyed, because 'user'
scripts tend to not release scarce resources.
* I need the scheduler (or any replacing subsystem) to work properly
for things like sleep(), preferably in a thread-local manner.

So let me get back to the situation I'm in:
* I can't make multiple independent interpreters because of the global
interpreter array
* I can't make child-interpreters and just run code on them because
they do not have a scheduler.This I have fixed, and threads doesn't
suffer from it
* I cannot destroy child interpreters because of some yet unknown
garbage collector destruction issue.
* Thus, I cannot have short-lived interpreters and long-lived ones.
Nor can I run in a multi-threaded server.

Thus, /for know/, the usefulness of mod_parrot has gotten somewhat
smaller. I really hope to see this fixed.

For my direct purposes, however, it isn't all that serious. I can
still abstract the handling of interpreters (as I was planning to
anyway), so that when this works, I can replace its implementation. I
can still re-organise much of the script-loading code, so that it is
the same whether I have a child interpreter or not. And I can make the
module warn and fail in a multi-threaded enviroment. All of this is
not ideal, but it will work and I can get ahead.

Kind regards,
Bart

>
> 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-0001.asc>
>
> ------------------------------
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
> End of parrot-dev Digest, Vol 48, Issue 8
> *****************************************