On 12/3/12 12:03 PM, Blake McBride wrote:
>
>
> On Mon, Dec 3, 2012 at 10:55 AM, Bob Arning <arning315 at comcast.net 
> <mailto:arning315 at comcast.net>> wrote:
>
>
>     On 12/3/12 11:42 AM, Frank Shearar wrote:
>
>               In true reentrancy each recursive call would essentially
>             get their own VM.
>             >
>             >They could, but what's in the VM that they really need a
>             separate copy of?
>
>         It's not the VM, it's the shared state of the image that would
>         cause a
>         problem (if anything did). I would think, at least.
>
>     If that were the case, then he would need not only his own VM, but
>     his own image. If these calls from C are expecting a virgin image
>     with the ability to execute arbitrary smalltalk code and never see
>     anybody else's data, then a separate image (or at leat super
>     sandbox) would seem a requirement. OTOH, if he wanted to make use
>     of some BitBlt functions, e.g., then he could ship a bitmap to
>     Squeak, request some transformation and receive a new bitmap in
>     return. In this case, one Vm and one image would seem to do nicely.
>
>
>
> Yes, separate instance of the image.  It would be self-managed for 
> free of the global variables in the VM kernel were eliminated.  A 
> simple clone already loaded image function could make this work 
> relatively fast.
>
So, it sounds like what you need is
- a virgin squeak image for each call
- virgin VM globals pertaining to that image

And what you could, potentially, share is the VM excutable code. Since 
the VM code is a small part of the footprint, I think your requirements 
are basically met by a new VM/image for each call. Not sure there is 
much to be saved getting a new image and keeping the same VM.


Cheers,
Bob
>
>
>     Cheers,
>     Bob
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121203/8f371583/attachment.htm