dynops and multiple interpreters

[Allison Randal]

Jeff Horwitz wrote:
> i ran into a major stumbling block during my latest mod_parrot hackathon.
> 
> mod_parrot supports global, per-server, and per-section interpreter 
> pools. new interpreters are created using Parrot_new, passing in the 
> parent interpreter if one has already been created.  all of this works 
> great when the only language in use is PIR, but once you throw rakudo 
> into the picture, things blow up pretty spectacularly.
> 
> rakudo uses dynops, and when both a parent and child interpreter load 
> rakudo, the child actually tries to load the dynops again, even though 
> they're already loaded and shared globally.  this can actually 
> "succeed", but it corrupts the parent interpreter in the process.  there 
> are checks to avoid this situation, but they are only triggered when 
> creating threads.  and even if they were triggered, they'd throw an 
> exception and i'd be stuck without rakudo.

In the short-term, the best solution is to trigger the same checks as 
threads in the child interpreter (assuming those checks are able to 
safely detect that the dynops are already loaded and globally shared), 
but instead of throwing an exception, simply succeed without reloading. 
It's essentially like Perl's 'use' (where a module is loaded once, no 
matter how many times various parts of the code 'use' it), or more 
primitively like ifdef-ing C header files so they're only included once.

> the child interpreter is NOT a clone, so i MUST reload rakudo in order 
> to use it.
> 
> i have several thoughts on this.  first, it seems to me that 
> dynop_register needs to be smarter in simple multi-interpreter 
> environments, doing the right thing or failing with an exception if it 
> can't.  second, we need a robust way to clone interpreters from an 
> embedded environment.  that way i can load all the HLLs up front and 
> clone as necessary.  that may be a post-1.0 discussion though.

Ultimately, we should be able to completely clone an interpreter, 
including loaded dynops and dynpmcs, and loaded libraries. You shouldn't 
  have to reload rakudo on every child interpreter.

The short-term solution doesn't conflict with the long-solution, and 
really should happen anyway.

Allison