On Wed, Jul 19, 2006 at 08:00:15PM +0900, Mauricio Fernandez wrote:
> 
> So it doesn't support concurrent non-sandboxed Threads, right?
> 
> require './sand_table.so'
> require 'timeout'
> 
> sbox = Sandbox.new
> Timeout.timeout(1) do
>   sbox.eval <<-EOF
>     # 3v1l
>     while true
>     end
>   EOF
> end
> 

Right, I don't have an answer for that yet.  I'd need to find a way to swap the
environment back in when the context changes.

> hangs. To be fair, there are many ways to circumvent timeout, so the sandbox
> would normally execute in a separate process (the way you do with Try Ruby
> IIRC). 

Yes, I will probably suggest forking the interpreter if many sandboxes will be
spawned from a single process.  It's plausible that this could be fixed, though,
with the creativity you or Guy or Matz or Nobu could so generously offer.

> This makes me think that the point of sandbox is not as much allowing access
> to stuff you cannot use with higher $SAFE levels as offering a clean
> environment. Am I right? In both cases, being able to specify which stuff is
> to be imported could be useful.

Exactly, possible uses:

* emulation of selector namespaces. (load 2 Rails apps at once.)
* dup'ing an environment. (gonna work on this today.)
* testing and simulation (create several environments under which to 
  run unit tests.)
* package management: load several versions of a library, use RubyGems
  in isolation.

Knowing Rubyists, I'm sure surprising things will start to appear.

_why