From: Tim Bates <tim@...>
Date: 2002-12-16T17:00:05+09:00
Subject: Sandboxing and threading

Dear all,
I have been pondering the idea of a RubyRobots for some time - this would be 
based on the idea (I think someone referred to it as 'robocode') where people 
can write a few snippets of code to control a robot and then battle different 
robots against each other. There would be functionality to allow tournaments 
of more than one robot, and regular playoffs could take place. As well as 
being a lot of fun, it is a great teaching tool.

Naturally, being RubyRobots, I intend for the robots to be written in Ruby. As 
well, being a Ruby enthusiast and not too great at C/C++, I want to write the 
controller itself in Ruby. But of course, there needs to be some level of 
separation between the controller and the robot, so that we don't have robots 
cheating or doing dastardly things by manipulating the controller. So I need 
to sandbox the robot somewhat. I'm just not sure what the best way to do this 
would be.

Ideally, I'd like to specify exactly which methods robots can use, but this 
could be a bit tedious and possibly flawed. Looking quickly at the pickaxe, 
it seems that $SAFE == 4 might be what I want, but I only want $SAFE == 4 
while the robot code is running. So, I considered putting the robots in 
threads - this solves some other implementation problems as well. However, I 
have very minimal experience with Java threading, and none with Ruby's 
threads (which I'm told are easier). I have no real understanding of what is 
threadsafe and what isn't, though.

So to converge more rapidly on the point of this email, I am going to outline 
below how I think this would work, and would appreciate the more thread-savvy 
of you pointing out anything that is wrong, un-thread-safe, or worth watching 
out for.

In a battle between n robots, I will have n + 1 threads - a controller thread 
and a thread for each robot. The robot threads will have $SAFE == 4; the 
controller, $SAFE == 0. Each robot thread will have two event queues 
associated with it. Robots will pass commands ("I want to turn left 30 
degrees") to the controller thread by putting events in the outgoing event 
queue, and the controller will pass information ("you have been hit and lost 
15 health points") by putting it in the appropriate robot's incoming event 
queue. The robots will also be able to get some information (such as their 
co-ordinates, health or ammo) by querying the controller directly, but this 
will be only modifiable by the controller, and indirectly by the robots by 
issuing commands to the controller.

Now, would this work as I'm proposing it? Is there a better way? What gotchas 
should I be careful of? I'm particularly worried that making $SAFE == 4 will 
prevent me from doing some things that I need to make it work.

Tim Bates
-- 
tim@bates.id.au