[Question] Having brains again after being headless?
PhiHo Hoang
phiho.hoang at rogers.com
Fri Dec 6 20:13:26 UTC 2002
Hi Ian,
> As for (un)loading (or reconfiguring) huge piles of Unix VM support code
> (GUI or otherwise) on demand, watch this space. ;)
Watching ;-)
Cheers,
PhiHo.
----- Original Message -----
From: "Ian Piumarta" <ian.piumarta at inria.fr>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, December 06, 2002 2:28 PM
Subject: Re: [Question] Having brains again after being headless?
> Hi PhiHo,
>
> On Fri, 6 Dec 2002, PhiHo Hoang wrote:
> > > I wonder if and how it is possible to send a headless squeak-process a
> > > signal, to show its gui again?
> >
> > I am a bit confused. What do you mean by 'again' ?
>
> The Unix VM is capable (via OSProcessPlugin primitives) of closing its
> connection to the display server (and hence the window) without exiting
> (it continues to run the image). The display primitives continue to
> succeed, but they're no-ops. This is "decapitation".
>
> Hence "capitate", which is reopening the display connection to create a
> new window, into which the display primitives will start drawing again.
>
> > A headless Squeak process should not have any
> > gui related thing in it, or, well, just a tiny little bit
> > (like in SqueakScript pre-alpha release :-).
>
> The Unix VM (with display support compiled in) can be started with the
> `-headless' option, which simply omits to open the initial display
> connection (and hence window); i.e., it starts up "decapitated". If you
> later want a window, the VM can "(re)capitate" itself (via OSPP) for you.
>
> FWIW, the advantage of doing all of this with a signal would be that the
> image need not even be paying attention to whether it's currently headless
> (or setting up a listening socket, or redirecting signals to semaphores,
> or whatever). The necessary code is already all there (at least in the
> Unix VM) in order to support the corresponding OSPP primitives.
> Connecting a signal to the "reconnect" code adds about 5 lines (and not
> very many more bytes) to the VM. (A signal-based approach would be
> entirely familiar to Unix hax, who are used to sending signals to
> processes to tell them to modify their behaviour on-the-fly. Stephen and
> Dave, OTOH, have approaches much more in line with Squeak's "philosophy".)
>
> As for (un)loading (or reconfiguring) huge piles of Unix VM support code
> (GUI or otherwise) on demand, watch this space. ;)
>
> Regards,
>
> Ian
>
>
More information about the Squeak-dev
mailing list
|