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
