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 > ***************************************** _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
