[squeak-dev] New Cog VMs available

Blake McBride blake at mcbride.name
Mon Dec 3 17:23:33 UTC 2012


Actually, here is a better description of the scenario, that would help
explain the solution.

Let's say I have a many-iteration-loop that needs to execute some Squeak
code.

1.  I first create a new instance of the Squeak VM with a cloned image.
 ONE TIME

2.  I then execute Squeak code to cause it to load some custom code needed
for that particular use case.  ONE TIME

3.  I then enter my C loop repeatedly calling the VM instance I just
created and initialized.  MANY TIMES

4.  When the loop is over I dispose of the Squeak instance.

There can be many of these scenarios running recursively at the same time.
 Each is totally independent.


On Mon, Dec 3, 2012 at 11:03 AM, Blake McBride <blake at mcbride.name> 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.
>
>
>
>>
>> Cheers,
>> Bob
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121203/04fb6bb7/attachment.htm


More information about the Squeak-dev mailing list