On 26 September 2012 13:44, David T. Lewis <lewis@mail.msen.com> wrote:
On Wed, Sep 26, 2012 at 11:55:25AM +0200, Igor Stasenko wrote:
On 26 September 2012 03:53, David T. Lewis <lewis@mail.msen.com> 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.
By pointers i meant references to external resources, like open files, sockets etc. They surely require additional handling, (some might remain open, but some should be closed ASAP), all this doesn't contributes to simplicity of implementation :) And handling properly X11 connection is just a single piece of puzzle.
Dave
-- Best regards, Igor Stasenko.