[squeak-dev] [OSProcess] #safeToForkSqueak when running headless

Eliot Miranda eliot.miranda at gmail.com
Wed Aug 13 13:28:10 UTC 2014

On Wed, Aug 13, 2014 at 5:23 AM, Max Leske <maxleske at gmail.com> wrote:

> On 13.08.2014, at 14:00, squeak-dev-request at lists.squeakfoundation.org
> wrote:
> Date: Wed, 13 Aug 2014 07:45:08 -0400
> From: "David T. Lewis" <lewis at mail.msen.com>
> Subject: Re: [squeak-dev] [OSProcess] #safeToForkSqueak when running
> headless
> To: The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> Message-ID: <20140813114508.GA5949 at shell.msen.com>
> Content-Type: text/plain; charset=us-ascii
> On Wed, Aug 13, 2014 at 09:42:50AM +0200, Max Leske wrote:
> Hi folks.
> I?m running into an issue when forking images with OSProcess in headless
> images. In older versions of OSProcess #forkSqueak would try to fork in any
> case, independent of the presence of or the connection state to
> XDisplayControlPlugin.
> In dtl.57 #forkSqueak was changed to explicitly check if
> XDisplayControlPlugin is present and can be controlled. This is obviously a
> good thing for when the image runs headful. In my case however I can no
> longer fork my headless image, even though I don?t need an X session.
> Important: apparently #safeToForkSqueak answers true if the
> XDisplayControlPlugin is available, even in a headless image. But since we
> don?t need windows, we don?t install X libraries on our server and so
> #safeToForkSqueak answers false. So the whole thing boils down to a
> situation where Squeak / Pharo is run in an environment where the
> XDisplayPlugin can?t be loaded but where forking is still possible.
> I don?t know how to do this in a cross platform way but for Pharo we could
> extend #safeToForkSqueak with a headless check like this:
> safeToForkSqueak
> "The forkSqueak method is currently supported only for X11 displays with
> XDisplayControlPlugin available. If the plugin is not available, the child
> Squeak
> VM will continue interacting with the X display, which leads to errors in
> the
> parent Squeak, including VM crashes."
> ^self canControlXDisplay
>  or: [ Smalltalk isHeadless ]
> I?m going to dirty patch this for my images because I really need it but I
> think some version of this patch would be a good thing to integrate into
> OSProcess.
> Hi Max,
> Thanks for this fix. I'll add it to the OSP repository as soon as I have a
> chance (but maybe not until Sunday).
> As a side note, I have also found that an active RFB (VNC) connection
> presents
> a similar issue. If I have a headless image (such as a SqueakSource
> server), and
> if I have a VNC session connected to that image, then a forkSqueak does
> bad things
> because it results in two instances of the VM/image connected to the same
> socket.
> This is the same kind of issue as with the X11 server socket connection,
> so I should
> probably find a way to handle this in the safeToForkSqueak checks.
> We explicitly check for that and forbid forking if there’s an RFB session.
> We also do a couple of other things before forking to make sure we don’t
> run into problems. One of the most important things for us is to stop WAKom
> before the fork and restart it afterwards. Otherwise the child would
> sometimes steal the socket or would crash etc.
> Forking is realy a bit of a can of worms and I’m really happy that it
> still works so reliably. So thanks for that :)

Should it be doing something to the effect of Smalltalk
processShutDownList:/processStartUpList: around the fork?  I can see this
is problematic cuz one won't want to shut down the kernel (Delay etc) or
OSProcess itself.  But an arbitrary set of things may need to shutDown and
restart and the start-up and shut-down lists are the pluggable mechanism.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140813/04a49e7c/attachment.htm

More information about the Squeak-dev mailing list