From: gwtmp01@...
Date: 2006-02-24T13:05:24+09:00
Subject: Re: Launching Ruby scripts and the future of MVM


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.

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.
Then you would have the problem of which classes are defined in which  
context.
If it is the same, then why multiple contexts?  If it is different  
then your
inter-context communication/data sharing just became a lot more complex.

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'm not a Windows guy, maybe there are limitations in that  
environment (especially
with fork/exec) that I'm just not aware of.

Gary Wright