2009/8/28 Schwab,Wilhelm K <[email protected]>: > Sig, > > I must disagree, because there is more to what I am saying than simply to > skip cleanup (I am saying to do it in two parts, each at the correct time and > only at the correct time). Further, the current behavior has nothing to do > with shutdown - it is done pre and post snapshot. Dolphin has it right; we > should borrow the idea. >
Oh, yes, i mistaken. I by shutdown i meant snapshot. Its just from current Squeak POV shutdown is always performed before snapshot. > Bill > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Igor > Stasenko > Sent: Thursday, August 27, 2009 8:26 PM > To: [email protected] > Subject: Re: [Pharo-project] Startup/shutdown > > 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 > _______________________________________________ > 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
