From: Paul Brannan <paul@...>
Date: 2002-02-23T06:57:01+09:00
Subject: Re: Ruby's Future

On Sat, Feb 23, 2002 at 06:19:51AM +0900, Sean Middleditch wrote:
> 1.  Precompiled blocks.  Let these byte-codes (hell, even an XML dump of
> the code tree) be loadable without the full compiler.  Similarly, eval
> would have be optional.  These *are* big bits of code that aren't needed
> for apps that need simpler scripting.

eval is optional.  Instead of doing this:
  eval(x)

you can do this:
  my_proc = eval("proc { |a,b,c| #{x} }")
  my_proc.call(a, b, c)

For tasks that aren't computationally intensive, I notice a 4x
improvement in speed doing this.

> 2.  Reentrant.  Ruby/Rite should let multiple instances of the
> interpreter run at in the same ( or even different ) threads.  The
> usefulness with be apparant with the features below.

Definitely.  And get rid of those global variables.

> 3.  Breakable execution.  I might want to let a script/Ruby thread run,
> but I'd need my app to continuously run as well (think network or GUI
> apps).  if the Ruby script has a bug (infinite loop), I don't want my
> whole app to lock up.  The app should be able to say "run for 500
> milliseconds tops" or "run for 300 expression evaluations."  The thread
> could then be "frozen", the controlling app does its work, then lets the
> script/thread continue.  The controlling app could do its own magic to
> put time limits on threads (to get rid of the scripts with infinite
> loops).

Hmm... is this what rb_thread_wait_for does?  There's no inline
documentation for many of these functions, so sometimes it's hard to
tell.

The way I handle this is with an ACE reactor; the reactor is wrapped so
I can add Ruby IO objects to the reactor.  99% of the time, my
application is sitting inside the reactor event loop.  When data is
available on an fd, a callback is made, either into C++ code or Ruby
code, depending on who registered the fd.  Ruby threads can be running
in the background while the reactor is sitting in an rb_thread_select
loop.

If a callback hangs, then the program will hang, but if a background
thread hangs, then I'm still safe.

> 4.  Optional non-blocking system requests.  The core I/O and other
> blocking requests (files and sockets) should have an option set for
> breaking block.  Let's say a script wants to read a file, and the
> request would block - instead, the script should be frozen (as in
> request 3 above) and the controlling app runs.  When it lets the script
> run again, it would check for blocking, read what it can, then break
> again if it would block again.  This way, if a script needs system I/O,
> it won't lock up the controlling application.

Would something like:

  io.fcntl(Fcntl::F_SETFL, Fcntl::O_NONBLOCK)

work?

(Granted, a nice wrapper library around this would be nice)

> 5.  Easily enable/disable core libs.  In some apps, it may be desirable
> to completely and totally disable some of the core libs (like I/O), and
> so on.  I would want to be able to not load the compiler/eval, not load
> I/O, and not allow require, in some of the apps I would embed Ruby in. 
> Lua lets you do this, which is nice.  (note: when I say disable I/O, I
> mean *all* I/O... even print())

I don't know why you'd want to do this, but why can't you simply iterate
over all the methods in IO and undef them?

> In any event, I know that's a big list of requirements for what I'd want
> in Ruby, but everyone has their list, right?  ~,^

I was pleased how short your list was :)

Paul