[squeak-dev] SecureSqueak

Igor Stasenko siguctua at gmail.com
Thu Mar 18 16:45:01 UTC 2010


On 18 March 2010 18:11, Josh Gargus <josh at schwa.ca> wrote:
> 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?)
>
Hey, i'm still having a lot of aces hidden in my sleeve , ready to be drawn :)
The last thing, i did with it is attempt to move closer to model,
where you can spawn a tiny object memory
from a main, big one, aimed for limited set of tasks.
Also, i got an island model, which can be adopted in Hydra, which
would allow us to have a cross-island references
and send messages between them.
There's a lot of ideas floating in my mind.. i hope that Cog will be
released soon, so we could start making next-gen things
based on a next-gen VM :)

> Cheers,
> Josh
>
>
>
>> -Ralph Johnson
>>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list