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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]> > Leto Labs LLC http://labs.leto.net > 209.691.DUKE http://dukeleto.pl _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
