<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 20, 2017 at 9:05 AM, 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:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
On Fri, Oct 20, 2017 at 06:40:47AM +0800, Ben Coman wrote:<br>
><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>
<span class="gmail-">> ><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>
</span>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, </blockquote><div><br></div><div>I forgot Fuel. I guess its binary nature would make it faster.  </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">although I'm sure 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></blockquote><div><br></div><div>Would it be efficient enough to benefit forking off the display rendering half of the world loop?</div><div>One thing I've seen in the past with Pharo with attempts to multi-thread UI components</div><div>is that #changed: is unwittingly called somewhere deep in morph code away from the level the components are put together, </div><div>and the rendering code is written assuming its the only thread, particularly with String producing race conditions like...</div><div>   bufferCopy := Array new: buffer length.</div><div>   1 to: buffer length do: [ :i | </div><div>         bufferCopy at: i put: (buffer at: i) ].</div><div>which goes bang when another thread causes buffer <br></div><div>gets longer between lines 1 & 2,</div><div>or gets shorter between lines 2 & 3.</div><div><br></div><div>And I sometimes wonder if the rendering occurred in a fork, then its copy of buffer would be fixed</div><div>and the race conditions could not occur.  The rendering-fork normally wouldn't even need to hand anything back in a join. It would just update the display and die quietly.  </div><div>How to keep debugging integrated would be interesting.  Maybe Fuel helps there anyhow.</div><div><br></div><div>cheers -ben</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></div></div>