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
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
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?)
> -Ralph Johnson
More information about the Squeak-dev