From: Austin Ziegler <halostatue@...>
Date: 2006-02-24T13:26:09+09:00
Subject: Re: Launching Ruby scripts and the future of MVM

On 2/23/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:> On Feb 23, 2006, at 6:20 PM, Logan Capaldo wrote:>> On Feb 23, 2006, at 5:42 PM, gwtmp01@mac.com wrote:>>> On Feb 23, 2006, at 5:05 PM, Charles O Nutter wrote:>>>> I tossed this message off to the Ruby-core list about a month ago,>>>> and sent a follow-up email today. The basic idea is that if there>>>> were a Kernel#run_script method or similar, all Ruby apps that want>>>> to launch external scripts could do so in a platform and>>>> implementation-independent way.>>> In what way is what you are proposing different from Kernel#system?>> 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> You already have coroutines, threads, fork/exec, system, and load/> require all of which give you different ways to manage multiple> threads of control and/or interpret external ruby code.
Right. But this is meaningfully different than all of the above,especially within the context of JRuby. JVMs are *expensive* to start,but independent Java threads are pretty easy to start. I think that theintent is that JRuby is going to introduce Kernel#run_script orsomething similar to it because they want to give JRuby programmers away to start an external script in a lightweight manner. The suggestionbeing made here is to reincorporate it into CRuby, something I support.
In CRuby (without multiple VM instances possible):	Kernel#run_script(name, *args)would be no different than:	Kernel#system("ruby", name, *args)
I'm not fond of the name (maybe Kernel#ruby might be appropriate) butthe functionality is appropriate, IMO.
> If you had two (or more) Ruby 'contexts' in a single process you would> still have to get memory management and IO to work correctly and you> would have two (or more) top-level objects and invariably you are> going to want to communicate between the two contexts which means> creating some sort of inter-context communication system, which would> have to play nice with the OS, other ruby threads and so on.
Actually, you may not. When you're calling Kernel#system, you don'tnecessarily want all of the above. You're often looking for a returncode that indicates that the command was run successfully ... and youdon't care if it's just a second VM that's started up to run the Rubyscript you just called. The VMs will have to do the synchronization toOS resources, but you won't, in either process.
This would certainly make Rake's default mode of operation for testsmore portable and reliable.
> It all sounds like a lot of work much that would end up still not> providing the features you already have with fork/exec (for example)> and I'm still not sure what problem is being addressed that can't be> solved with the existing toolset, which already has quite a few> options.
I think you're trying to overthink this. This is about reducing thestartup cost for JRuby at a minimum and future Ruby interpreters thathave multiple VM support. This isn't about pseudo-IPC within those VMs.
-austin--Austin Ziegler * halostatue@gmail.com               * Alternate: austin@halostatue.ca