<div dir="ltr">Somehow I'm reminded of Igor Stasenko work on the Hydra VM.  <a href="http://squeakvm.org/~sig/hydravm/devnotes.html">http://squeakvm.org/~sig/hydravm/devnotes.html</a><div>I did do a port for Mac OS back in 2008. </div><div><br></div><div>Also btw for the OSX browser Squeak plugin work I did 10 years back we would fork the VM and setup a shared memory location which shared the Screen bitmap between the running background only Squeak VM process and the plugin code in the browser that would get screen draw requests via a pipe from the Squeak VM process and with the use of a shared semaphore latch to prevent the Squeak VM from burying the Safari plugin with draw requests. </div><div><br></div><div>For this shared memory worked nicely as we didn't pipe MB of memory for a screen draw back to the Safari plugin. All the safari plugin knew was to copy the bit rectangle to the screen as ordered and signal the semaphore to let the VM continue running after it had done a screen sync cmd. </div><div><br></div><div>Morphic in this millennium  (not the last) generally issues a screen flush at the end of a 'drawing cycle' At that point the bits should go to the device that shows them to the user. Intermediate draws aren't particularly important but you can modify that visual aspect by forcing an update every 50 fps. Also maybe handy for last millennium code and obviously do the draw only if the bitmap has changed. <br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 6:05 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
On Fri, Oct 20, 2017 at 06:40:47AM +0800, Ben Coman wrote:<br>
<span class="gmail-">><br>
> On Fri, Oct 20, 2017 at 12:46 AM, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > > On 19-10-2017, at 7:31 AM, Todd Blanchard <<a href="mailto:tblanchard@mac.com">tblanchard@mac.com</a>> wrote:<br>
> > ><br>
> > > It works very well and this idea of mini worker images sounds like it<br>
> > might be a good fit for that model.<br>
> > ><br>
> ><br>
</span>> > One thing I noticed with surprise was how astonishingly fast Dave???s<br>
<span class="gmail-">> > OSProcess could spawn an entire image, even on a Pi. So it might be worth<br>
> > experimenting with spawning a child image to do some processing and maybe<br>
> > transmit results back via sockets or writing a project file or.. well,<br>
> > whatever. You might think that on a tiny thing like a Pi you would rapidly<br>
> > use up all memory and start disastrous paging to SD (ouch!) but a Pi has a<br>
> > Gb or ram and my 6.0alpha development image uses less than 9% of that.<br>
> ><br>
</span>> > It???s a potentially simple way to make some use of multiple cores.<br>
> ><br>
><br>
> Are talking about booting up a new image?<br>
> What about native-forking a running image.  Linux default copy-on-write<br>
> (IIUC) should help limit memory usage, with full access to existing objects<br>
> without needing to worry about multi-threaded access to objectspace.<br>
> The trick to work out would the join mechanism. Perhaps returned objects<br>
> would be limited to instance variables containing only immediate types and<br>
> plain arrays of the same.  Maybe the join mechanism would need to groom out<br>
> non-compliant objects at the VM level.  Or the join returns a STON<br>
> representation.<br>
><br>
> cheers -ben<br>
<br>
Yes that is exactly what Tim is talking about. The unix fork mechanism is<br>
suprisingly efficient when applied to a VM process running a Smalltalk image.<br>
Fuel works nicely for returning objects to the parent image, although I'm sure<br>
STON would work fine also.<br>
<br>
The Spur image format allows object memory to be segmented such that it will<br>
support fast and efficient forking of images even for extremely large images.<br>
I don't have any real world use cases to prove the point, but would be quite<br>
interested in finding some.<br>
<br>
The join mechanism can be very simple. The child image serializes the result<br>
of whatever work it has done, and writes it to a pipe connected to the parent<br>
image. The parent deserializes the next object from the pipe, and that is the<br>
result. As long as the pipe read does not block the VM (that is an OSProcess<br>
thing), you can put any number of child readers into separate Smalltalk processes.<br>
<br>
Background information is at <a href="http://wiki.squeak.org/squeak/6176" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/<wbr>6176</a>.<br>
<br>
Dave<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">===========================================================================<br>John M. McIntosh. Corporate Smalltalk Consulting Ltd <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div></div></div>
</div></div></div>