[squeak-dev] XDisplayControlPlugin

David T. Lewis lewis at mail.msen.com
Fri Apr 25 03:35:26 UTC 2014

On Thu, Apr 24, 2014 at 09:27:11PM -0500, Chris Muller wrote:
> 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..

I don't know. If it does not work with Cog, just run an interpreter VM
now and worry about Cog later. Maybe you will need to do a Cog build with
the plugin included, or maybe you will need to ask Eliot to include it when
he does the next build. Either way, there is no point in spending your time
on it right now (it definitely will work on Cog either now or in the near
future, just don't worry about it now).

> > 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?"

Yes, forkSqueak is non-blocking.

No, the returnValue has nothing to do with the evaluation in the remote image.
The two images are completely separate. But see RemoteTask.

> > 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?

Paging is completely dependent on the operating system. Most systems that
you are likely to encounter use a 4k page size, but this may change, and
earlier unix systems used various memory segmentation models that did not
directly use page swapping. This stuff is (and should be) very platform
dependent. The key thing is that systems that support the unix fork() mechanism
will generally know how to map memory to a forked process, and to map
memory into that process space in some reasonably efficient manner.

> > 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.

Think of #forkSqueak as "split off an exact copy of the currently executing
object memory" as opposed to "start a new program".

> > 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?

RemoteTask is in package CommandShell. CommandShell was part of OSProcess,
but long ago I split CommandShell out in the interest of modularity. The
CommandShell package is built on the unix pipe metaphor, and things that
use pipes are in CommandShell, as opposed to lower level OS and clib functions
that are supported in OSProcess.


More information about the Squeak-dev mailing list