Dave, this is very exciting!
Yes, it's used to close the X session in the child Squeak. Without that, you have two VMs talking to the same socket connection to the X11 server, which confuses all involved (and crashes the VM).
The plugin is included in the VMs at http://squeakvm.org/unix/. I think that you can just copy it into your Cog directory.
I copied it into the lib/4.0-2776 cog directory. But Squeak still doesn't list it in the "VM Modules" of System Reporter and, accordingly, gives me the same error when I try to forkSqueak.
Any ideas? I'm running cog-ht is that a problem?
I didn't yet try to run it with interpreter VM. What I want to do with it must work with Cog, otherwise I'd have to compromise any multi-core solutions with a much slower VM..
Eliot recently added a patch that makes forkSqueak work properly in Cog (yay!). I'm not sure if this has made its way into the precompiled Cog VMs, but I'm sure it be available soon. You should nag him to include XDisplayControlPlugin in the next build (and AioPlugin also).
In the mean time you can use a VM from squeakvm.org. There's nothing wrong with switching back and forth between interpreter VM and Cog, I do it all the time :-)
I want to try this:
| a | a := Array new: 1. OSProcess thisOSProcess forkHeadlessSqueakAndDoThenQuit: [ a at: 1 put: 'one']. (Delay forSeconds: 5) wait. a "#('one')? or #(nil)?"
The result will be nil. The object memory in the child squeak is an exact copy of the one in the parent. Changes in the child will not be visible in the parent, and vice versa.
Good, that's exactly what I hoped. And, it makes sense too, because if the forked squeak were overwriting the same memory and sharing object memory with another VM, it'd be useless and probably just crash anyway.
So, the next thing I want to try is:
| returnValue | returnValue := OSProcess thisOSProcess forkHeadlessSqueakAndDoThenQuit: [ 123 ]. (Delay forSeconds: 5) wait. "<--- temporary stop gap, I assume forkSqueak is non-blocking, of course!" returnValue "I know this won't be 123, right?"
Actually, it is more interesting than "exact copy". Initially the two object memories occupy the same physical memory, mapped to the two VM processes. As the two VMs make changes to their object memories, the operating system will map pages as needed into the virtual memory spaces of the two VMs. As the two object memories change, they begin to consume additional real memory.
I've always been utterly fascinated by this, but never had a full grasp about what parts of memory were actually copied as they were overwritten. I think you answered that -- it's a "page" at a time. Curious, how big is a page?
This is already a remarkably memory efficient process when creating child Squeak processes that do a limited amount of work.
Indeed! I've been using a new framework for about a year now that uses OSProcess to fork entire copies of the running Squeak image to perform large multicore tasks.
I believe what I'm using is platform independent, because it just uses OSProcess command: <the squeak vm executable>, but I want to see if I can take advantage of #forkSqueak when a Linux system is detected.
I expect that the object memory localization in Spur should make it even better, since new objects can be localized in the object memory address space, and the changes that require page allocation from the operating system will therefore be much more limited.
Hint: Try evaluating "RemoteTask threeParallelTasks" to get an idea as to what might potentially be done with forked Squeak processes.
Sounds interesting. What package is RemoteTask in?
Thanks!