XDisplayControlPlugin location?

> On Tue, Sep 25, 2012 at 12:23:38PM -0700, Paul DeBruicker wrote:
> > Hi-
> >
> > Where can I find the latest XDisplayControlPlugin? Is this it:
> > http://wiki.squeak.org/squeak/3350 ?
> >
>
> That's my original "home page" for XDisplayControlPlugin. The code is
> now kept on SqueakSource:
>
>   http://www.squeaksource.com/XDCP
>
>
> >
> > I was trying to run
> >
> > UnixProcess saveImageInBackgroundNicely
> >
> >
> > in Pharo-1.4 using both Eliots and the inria vm's but can't because I
> > don't have the aforementioned plugin.
> >
>
> I'm not sure if this works on Cog. I think it should work, but I'm
> away and can't check for sure. But FYI #forkSqueak has some limitations
> on Cog, e.g. you cannot fork a vm/image and reopen the display in
> the child.

> On Wed, Sep 26, 2012 at 03:24:51AM +0200, Igor Stasenko wrote:
>> As i understood, this features doing a snaphot in forked child process.
>> Is this involves doing #shutdown on image side in forked process, or shutdown
>> done in parent image?
>
> It just forks an identical copy of the VM and image in a background process
> running at lower priority, and does the image save in the background process
> so there is no effect on the main image. Each of the two images knows if
> it is parent or child, so the child evaluates a block (to do the image
> save) then exits.
>
>> Alas, the complexity of VM works against us in this case :/
>> It is not just object memory, but open files, sockets and god knows
>> what else (other external resources used by image).
>>
>
> It is not the Cog VM that is too complex, it's the use of pthreads in
> the support code for basic timer support that makes it tricky. I'm sure
> it can be done, but it's not trivial.
>
> Handling the socket connection to the X11 server was a challenge, but
> I was able to do that with XDisplayControlPlugin. The remaining file
> handles are just shared between the processes and do not cause any
> immediate problem. Signal handlers were also an issue, mainly for
> the timer interrupts.
>
> I don't think you should be surprised that it does not work in Cog,
> instead you should be surprised that it works at all on any VM ;)
>

> On 26 September 2012 03:53, David T. Lewis <[hidden email]> wrote:
> > On Wed, Sep 26, 2012 at 03:24:51AM +0200, Igor Stasenko wrote:
> >> As i understood, this features doing a snaphot in forked child process.
> >> Is this involves doing #shutdown on image side in forked process, or shutdown
> >> done in parent image?
> >
> > It just forks an identical copy of the VM and image in a background process
> > running at lower priority, and does the image save in the background process
> > so there is no effect on the main image. Each of the two images knows if
> > it is parent or child, so the child evaluates a block (to do the image
> > save) then exits.
> >
> >> Alas, the complexity of VM works against us in this case :/
> >> It is not just object memory, but open files, sockets and god knows
> >> what else (other external resources used by image).
> >>
> >
> > It is not the Cog VM that is too complex, it's the use of pthreads in
> > the support code for basic timer support that makes it tricky. I'm sure
> > it can be done, but it's not trivial.
> >
> > Handling the socket connection to the X11 server was a challenge, but
> > I was able to do that with XDisplayControlPlugin. The remaining file
> > handles are just shared between the processes and do not cause any
> > immediate problem. Signal handlers were also an issue, mainly for
> > the timer interrupts.
> >
> > I don't think you should be surprised that it does not work in Cog,
> > instead you should be surprised that it works at all on any VM ;)
> >
>
> Yes, this is mainly what i expected to hear.
> Fork is very easy to use for a simple and small command-line programs,
> but once you start using things like pthreads, external connection(s),
> and FFI this getting more and more complicated, if not impossible,
> because you need a single point in your program which knows everything
> about all external resources/handles claimed by your program and the
> way how to properly disconnect them (as well as invalidate pointers to
> it) when forked..
>

> On Wed, Sep 26, 2012 at 11:55:25AM +0200, Igor Stasenko wrote:
>> On 26 September 2012 03:53, David T. Lewis <[hidden email]> wrote:
>> > On Wed, Sep 26, 2012 at 03:24:51AM +0200, Igor Stasenko wrote:
>> >> As i understood, this features doing a snaphot in forked child process.
>> >> Is this involves doing #shutdown on image side in forked process, or shutdown
>> >> done in parent image?
>> >
>> > It just forks an identical copy of the VM and image in a background process
>> > running at lower priority, and does the image save in the background process
>> > so there is no effect on the main image. Each of the two images knows if
>> > it is parent or child, so the child evaluates a block (to do the image
>> > save) then exits.
>> >
>> >> Alas, the complexity of VM works against us in this case :/
>> >> It is not just object memory, but open files, sockets and god knows
>> >> what else (other external resources used by image).
>> >>
>> >
>> > It is not the Cog VM that is too complex, it's the use of pthreads in
>> > the support code for basic timer support that makes it tricky. I'm sure
>> > it can be done, but it's not trivial.
>> >
>> > Handling the socket connection to the X11 server was a challenge, but
>> > I was able to do that with XDisplayControlPlugin. The remaining file
>> > handles are just shared between the processes and do not cause any
>> > immediate problem. Signal handlers were also an issue, mainly for
>> > the timer interrupts.
>> >
>> > I don't think you should be surprised that it does not work in Cog,
>> > instead you should be surprised that it works at all on any VM ;)
>> >
>>
>> Yes, this is mainly what i expected to hear.
>> Fork is very easy to use for a simple and small command-line programs,
>> but once you start using things like pthreads, external connection(s),
>> and FFI this getting more and more complicated, if not impossible,
>> because you need a single point in your program which knows everything
>> about all external resources/handles claimed by your program and the
>> way how to properly disconnect them (as well as invalidate pointers to
>> it) when forked..
>>
>
> It certainly is complex, and gets more so as additional external factors
> are added (e.g. pthreads). But it will never become impossible for the
> following reason: The image already has, and must have, a mechanism for
> snapshotting itself and resuming in another process space (that's what
> happens every time you start your image from disk). So I expect there
> is always going to be some way to make #forkSqueak work on a unix-based
> system. Of course I am not volunteering to actually *do* that, just
> saying ... ;)
>
> BTW, there is no need to invalidate pointers. The virtual address space
> remains valid after a fork. Most things "just work" after a unix process
> fork, but you do need to think about things like two processes holding
> references to the same socket connection to an X server, hence the
> use of XDisplayControlPlugin to disconnect the X display and reconnect
> to the X11 server after the fork.
>