<br><br><div class="gmail_quote">On Mon, Dec 3, 2012 at 10:55 AM, Bob Arning <span dir="ltr"><<a href="mailto:arning315@comcast.net" target="_blank">arning315@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 12/3/12 11:42 AM, Frank Shearar wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In true reentrancy each recursive call would essentially get their own VM.<br>
><br>
>They could, but what's in the VM that they really need a separate copy of?<br>
</blockquote>
It's not the VM, it's the shared state of the image that would cause a<br>
problem (if anything did). I would think, at least.<br>
</blockquote></div>
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.<br>
</blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Bob<br>
<br>
</blockquote></div><br>