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.

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.

If the remote images are short-lived and do not do things that result
in a lot of garbage collection, then the overall memory usage is
surprisingly light. I presume that this would do reasonable things
on a multiprocessor system also, although I don't have a system to
try it on.

Dave