I think you are correct.

On Mon, Dec 3, 2012 at 11:19 AM, Bob Arning <arning315 at comcast.net> wrote:

>
> 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> 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/6a85187d/attachment.htm