As a compromise, i suggest to introduce 2 different shutdown modes: - with cleanup - without cleanup
and then reflect it in UI, or in system preferences. Case closed :) 2009/8/28 Schwab,Wilhelm K <[email protected]>: > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
