[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Launching Ruby scripts and the future of MVM

Gary Wright

2/23/2006 10:42:00 PM


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?

Gary Wright
7 Answers

Logan Capaldo

2/23/2006 11:21:00 PM

0


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?
>
> Gary Wright
>
>
>
>

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.

Charles O Nutter

2/24/2006 12:36:00 AM

0

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 <logancapaldo@gmail.com> 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.

Gary Wright

2/24/2006 4:05:00 AM

0


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

Charles O Nutter

2/24/2006 7:07:00 PM

0

> > 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 the
> intent is that JRuby is going to introduce Kernel#run_script or
> something similar to it because they want to give JRuby programmers a
> way to start an external script in a lightweight manner. The suggestion
> being 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) but
> the functionality is appropriate, IMO.

I'd only correct this by saying we'd really *like* to add something
like Kernel#run_script/ruby, but unless existing apps were ported to
use it (necessitating its existance in CRuby) it wouldn't accomplish
much for us.

> This would certainly make Rake's default mode of operation for tests
> more portable and reliable.

This is, in fact, the exact use case we're having trouble with. As
JRuby gets closer and closer to full Ruby compatibility, we have been
starting to run more and more test cases against it. Many of these are
most easily run using rake, but two issues with JRuby make that
scenario less than ideal: 1. Launching new JVMs is very expensive, and
2. Java's support for launching and controlling external processes is
far more clunky than it is in POSIX. We have managed to hack around
the launching by intercepting Kernel#system calls, searching for
"ruby" or "jruby" in the beginning of the command, and if found
launching the appropriate script within the same JVM. The two
instances of JRuby are treated independently, as though they were
separate processes. It works, but it makes me itch.

> I think you're trying to overthink this. This is about reducing the
> startup cost for JRuby at a minimum and future Ruby interpreters that
> have multiple VM support. This isn't about pseudo-IPC within those VMs.

I have seen MVM mentioned in at least a couple YARV presentations, and
I think it's a good idea in the long term to be able to launch a new
script in a new Ruby "VM" without launching a whole new process. I
also think the script-launching method would make firing off scripts
easier both now and in the future. Here's hoping it happens!

--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com

YANAGAWA Kazuhisa

2/25/2006 3:54:00 AM

0

Just a simple note and no further info but....

Very recently ko1, the YARV developer, wrote that preliminary multiple
VM implementation had been done in his diary / blog / something such.

# He also wrote that it's too hackish / ad-hoc too commit, though.


MVM itself is considered useful especially for shared interpreter
environments such as mod_ruby, or providing more complete sandbox.


--
kjana@dm4lab.to February 25, 2006
Dreams come true --- excepting yours.

Charles O Nutter

3/3/2006 10:05:00 PM

0

And a friendly reminder about the RCR...I think this would be a really
nice feature to add. :)

http://www.rcrchive.net/rc...

On 3/3/06, Charles O Nutter <headius@headius.com> wrote:
> Just to keep this discussion going, anyone want to take a stab at a
> sample implementaton of Kernel#ruby based on how Rake does it? Rake
> defines two methods in its FileUtils class: 'sh' and 'ruby'. 'sh'
> provides a somewhat neater interface to running a system command with
> or without a shell, where 'ruby' provides a way to simply execute a
> Ruby command line using the approprate executable, passing args
> directly. In all, it's about 40 lines of code, and the 'sh'
> implementation may be unnecessary for our Kernel purposes. The key bit
> of logic, though, is how it gets the ruby interpreter to run:
>
> RUBY = File.join(Config::CONFIG['bindir'],
> Config::CONFIG['ruby_install_name'])
>
> If called within Ruby 1.8.x, Kernel#ruby(args, script) would most
> likely just use the above definition of RUBY and the specified args
> and/or script (or some other organization of command-line params) to
> launch an external process. In a multi-VM-aware interpreter, however,
> it could simply launch a second VM as appropriate, avoiding the second
> process entirely.
>
> --
> Charles Oliver Nutter @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com
>


--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com

Charles O Nutter

3/3/2006 10:05:00 PM

0

Just to keep this discussion going, anyone want to take a stab at a
sample implementaton of Kernel#ruby based on how Rake does it? Rake
defines two methods in its FileUtils class: 'sh' and 'ruby'. 'sh'
provides a somewhat neater interface to running a system command with
or without a shell, where 'ruby' provides a way to simply execute a
Ruby command line using the approprate executable, passing args
directly. In all, it's about 40 lines of code, and the 'sh'
implementation may be unnecessary for our Kernel purposes. The key bit
of logic, though, is how it gets the ruby interpreter to run:

RUBY = File.join(Config::CONFIG['bindir'],
Config::CONFIG['ruby_install_name'])

If called within Ruby 1.8.x, Kernel#ruby(args, script) would most
likely just use the above definition of RUBY and the specified args
and/or script (or some other organization of command-line params) to
launch an external process. In a multi-VM-aware interpreter, however,
it could simply launch a second VM as appropriate, avoiding the second
process entirely.

--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com