[squeak-dev] XDisplayControlPlugin

David T. Lewis lewis at mail.msen.com
Thu Apr 24 23:13:08 UTC 2014

On Thu, Apr 24, 2014 at 01:51:10PM -0500, Chris Muller wrote:
> Hi Dave, I am interested in playing around with #forkSqueak, et al.
> Do you know where I can find a precompiled XDisplayControlPlugin?  It
> wanted it even when I tried to use forkHeadlessSqueakAndDoThenQuit.

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.

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.

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.

This is already a remarkably memory efficient process when creating child
Squeak processes that do a limited amount of work. 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.


More information about the Squeak-dev mailing list