<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 20, 2017 at 12:46 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 might be a good fit for that model.<br>
><br>
<br>
One thing I noticed with surprise was how astonishingly fast Dave’s OSProcess could spawn an entire image, even on a Pi. So it might be worth experimenting with spawning a child image to do some processing and maybe transmit results back via sockets or writing a project file or.. well, whatever. You might think that on a tiny thing like a Pi you would rapidly use up all memory and start disastrous paging to SD (ouch!) but a Pi has a Gb or ram and my 6.0alpha development image uses less than 9% of that.<br>
<br>
It’s a potentially simple way to make some use of multiple cores.<br></blockquote><div><br></div><div>Are talking about booting up a new image?</div><div>What about native-forking a running image.  Linux default copy-on-write (IIUC) should help limit memory usage, with full access to existing objects without needing to worry about multi-threaded access to objectspace.</div><div>The trick to work out would the join mechanism. Perhaps returned objects would be limited to instance variables containing only immediate types and plain arrays of the same.  Maybe the join mechanism would need to groom out non-compliant objects at the VM level.  Or the join returns a STON representation.</div><div><br></div><div>cheers -ben</div></div><br></div></div>