[squeak-dev] [OSProcess] #safeToForkSqueak when running headless
David T. Lewis
lewis at mail.msen.com
Tue Aug 19 01:48:57 UTC 2014
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:
> "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.
I added your patch to the OSP repository. I added a check so that it will work
on classic Squeak 3.8 as well as the latest Squeak trunk and Pharo.
More information about the Squeak-dev