From: Charles O Nutter Date: 2006-02-24T09:35:44+09:00 Subject: Re: Launching Ruby scripts and the future of MVM Logan is spot-on with this interpretation. The intent is somewhat selfish - to provide a means for scripts-that-launch-scripts to run smoothly under JRuby - but I think it's going to be a valid scenario in Ruby's own future with the advent of Rite and the possibilities of MVM. It may also eliminate some headaches of launching external scripts; you don't need to know where the Ruby executable is or what it's called...you just tell Ruby to launch a script in whatever way is appropriate. Ideally something like this would be incorporated as soon as possible, so that existing applications could start using it ASAP. It would also be extremely low-impact to the existing interpreter since it would initially first just defer to Kernel#system to run scripts. - Charlie On 2/23/06, Logan Capaldo wrote: > system(x) # x is arbitrary shell command > run_script(x) # x is guaranteed to be a script written in ruby > > This means for instance, that run_script could get away with not > forking a new process, but rather just a new ruby VM assuming that > the ruby implementation had that capability > In the OPs example, using system to run another ruby script is > going to cause a whole new JVM to be created, along with the overhead > of a new ruby interpreter. Apparently JRuby has the ability to have > multiple instances of ruby per process. By incorporating this method > into ruby, scripts that want to run other ruby scripts can run faster > than they do currently (and no slower). In the C implementation of > ruby of course run_script could easily be implemented in terms of > system, but the JRuby guys would be able to implement it in a more > performant manner for their situation. Likewise YARV could > theoretically create a new instance of itself instead of a whole > nother process.