I am not so sure it will not be a big deal. With an open system, there is no reason not to use development tools to make changes on production machines, and saving the image would be part of that process; every occurance would clobber all sockets, all web users, all database connections, etc. It's something that just feels wrong in capital letters, and we are trying to fix things.
It definitely smells bad from a scientific computation perspective where external connections and saving the image are very common. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Miguel Enrique Cobá Martinez Sent: Thursday, August 27, 2009 7:57 PM To: [email protected] Subject: Re: [Pharo-project] Startup/shutdown El jue, 27-08-2009 a las 20:23 -0400, Schwab,Wilhelm K escribió: > Hello all, > > I am doing some more porting and hitting some trouble spots - no real > surprise that they exist. However, I am struck by a strong belief that > Dolphin has a lot of things right, and startup and shutdown is very high on > that list. > > No offense to Nicolas, who has been quite helpful, let's consider a somewhat > extrmeme example. Suppose a server is using an ORB to do SSL protected > communications with various servers and clients, some Seaside work, and has a > few database connections open. Are we content with having to close and > reopen all of that just to save the image? I submit that this is a flawed > design. Worst case, the vm knows when it loads an image and could tell the > image that it happened. From there, a lot of extra work could be dumped. > > Nicolas is quite right that step (2) below must be done carefully, but it has > been handled nicely in Dolphin by registering potential offenders in the > startup triggers and doing the cleanup at that time. External resources are > released on a shutdown trigger, but not image save. This will strike again > with native windows, as the current approach would (stop me if this is a > fallacy) have everything released and reopened on image save, which would be > very inefficient. > > I have code that expects a class called SessionManager, and I am seriously > thinking of creating it. It would trigger events for starup and shutdown, > help with logging, etc. Can it be donw without hacking the vm? > Just a question, what is the big deal with this, as you most often save on a development environment and not in a production environment. And as the number of saves on a production environment are seldom, it isn't a problem I think. In the dev enviroment you are pointing to dev services and you have few open conections/whatever so that is not a big deal either. > Bill > > > > =========================================================== > > [Pharo-project] Save and quit vs. Save - a clue to performance??? > Nicolas Cellier nicolas.cellier.aka.nice at gmail.com Thu Jul 16 > 22:48:34 CEST 2009 > > * Previous message: [Pharo-project] Save and quit vs. Save - a clue to > performance??? > * Next message: [Pharo-project] Save and quit vs. Save - a clue to > performance??? > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > Current policy is to cleanup before saving, and reconnect after saving > as if a fresh startup occured As you seem to suggest, a possible > alternative without using fork would be to: > 1) distinguish whether this is a newly restarted image (primSnapshot > returning true or false...) > 2) perform all the clean-ups at startup if newly restarted image > 3) rely on the process exit() to perform required resource clean-up in > case we quit (or let a self aboutToQuit do some) > > Step 2) would deserve great care, any unprotected access to an > uninitialized pointer of the old image would crash or trash memory... > > Nicolas > > 2009/7/16 Schwab,Wilhelm K <bschwab at anest.ufl.edu>: > > Nicolas, > > > > One thing I forgot to mention: thread safety??? IIRC, Dolphin triggers > > startup events, and all external resources clear pointers then (though they > > will release on shutdown, not image saving) to force a lazy connection. > > > > I see why, absent help from the vm, the image does not know when it starts > > and stops. What I do not get is why the vm does not tell it. If it did, I > > _think_ we could clean all of this up. Sometimes the truth hurts though, > > so please find any faults in my logic (or lack thereof). > > > > Bill > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
