David T. Lewis wrote:
> On Tue, Aug 08, 2006 at 09:29:00PM +0100, Michael Roberts wrote:
> 
>>On 8 Aug 2006, at 10:03, Michael van der Gulik wrote:
>>
>>
>>>Hi Howard.
>>>
>>>I forgot to mention that the reason I'm doing this is to allow  
>>>untrusted foreign code to run in the same image as trusted code.  
>>>Untrusted code must be carefully managed - it must not be able to  
>>>consume large amounts of memory, CPU or disk space to which it is  
>>>not entitled. Untrusted code / objects must not prevent trusted  
>>>code from operating well.
>>
>>This is not exactly what you asked for, but -
>>
>>as an experiment why not run your untrusted code in a separate  
>>image?  If you were running this on unix then you could limit the  
>>memory given to this separate image - either via say ulimit in the  
>>shell or something fancier (maybe via the os process plugin).  You  
>>could then talk to the 'jail' image via remote messaging.  It  
>>wouldn't take very long to knock up and it might give you interesting  
>>results early.

That idea actually has potential. I'll ponder on it. Some methods of 
keeping it OS independant would need to be thought about.

Hmm. It would mean that objects in separate domains couldn't reference 
each other.

> An easy way to do start the remote images is UnixProcess class>>forkSqueakAndDo:,
> but you'll want to do something to make sure the remote images are not
> writing to their original changes file, otherwise you'll have a swarm
> of images all scribbling on the same changes file.

Yea; I've been hit with that problem already. Damn near lost my code. I 
should record that as a bug in Squeak - the changes file needs a lock 
system on it so that only one Squeak instance writes to it.

In fact, I've gotten to the stage of saving everything to Monticello 
after every small change, and then restarting the image after I run it 
(the code I have so far completely frobs the image beyond repair...).

Michael.