If you are on Linux, there is a add-on package for OSProcess called CommandShell which includes a class called RemoteTask. It lets you fork a block of code to a separate OS thread and return the result to the calling image via serialization (Fuel or other).
IIUC, it takes advantage of Linux memory copy-on-write sharing, so the forking overhead should be proportional to the amount of work done (e.g., memory changes). On Wed, Nov 18, 2015 at 3:56 PM, EuanM <[email protected]> wrote: > (And yes, I know it's actually here already). > > Now that clock-speed rises have stalled, basically forever, desktop > and laptop PCs are growing ever-increasing numbers of cores in their > CPU chips, > > Is there design and conceptualisations work going on to see how Pharo > will deal with providing increased access to the additional processing > power? > > > One thing I have been thinking about is a set of co-operating Pharo VMs. > > But given memory and storage are shared, this may not provide as large > a benefit as we'd like. > > Or moving Pharo into being having multiple native-threads, and taking > Pharo into a concurrency route. > > Or - whatever it is I am too ignorant to see. > > This all strikes me (like the way Smalltalk is extending its system > boundary out onto the web with Monticello, Pharo is extending that > via the Configuration Browser and Versionner) as a way Pharo could > build on Smalltalk, while becoming its own thing. (as opposed to > being a Smalltalk with a very big set of classes). > > Is there thought work going on in this area yet? > > DabbleDB had a system of running multiple VMs on a server, and > hot-swapping them in and out depending on their CPU loading. > > Did that ever get developed intop a more generally-useful facility? >
