[squeak-dev] SecureSqueak

Josh Gargus josh at schwa.ca
Thu Mar 18 16:11:34 UTC 2010


On Mar 18, 2010, at 8:25 AM, Ralph Johnson wrote:

> In my opinion, if you want to grab some code off the internet and run
> it in a sandbox, you should spawn a slave image and run it inside that
> image.  The VM should ensure that any important requests have to go
> through the master image.
> 


This is a pragmatic approach, but to say that this is all that you'll ever need is akin to saying that there isn't any reason for E to exist.  I'm glad that there are people like Gulik and Mark Miller who are trying to attack the hard problem.


> In the same way, Croquet really ought to run each island as a separate
> image.  


Our experience shows that the right direction may be to have a large number of fine-granularity islands.  In such an architecture, it's not feasible to run each island in it's own image, since at the very least you would lose fine-grained control over scheduling (i.e. you would be at the mercy of the platform scheduler).  However, I agree what you say below:  to have 1 image per core and to distribute the islands between these images.


> The UI ought to be able to look into each island to display
> it.  This would make it easy to prvent cross-island references.
> 


Could you elaborate on how you see this working?  Traversing a 3D scene-graph involves touching a lot of objects, and it seems inefficient to have a master image essentially send IPC requests to slave images to perform the traversal (maybe I'm reading the words "look into" too literally?).


> Similarly, the way to write parallel programs is to spawn an image for
> each core. In general, a single image should be a single process.  It
> should be easy to develop an application that consists of a set of
> images.
> 


Agreed.  We have a great start for this with HydraVM.  Hopefully we find the energy to finish the job.

(Wow, why didn't we think of HydraVM as a Google Summer of Code idea?)

Cheers,
Josh



> -Ralph Johnson
> 




More information about the Squeak-dev mailing list