I’m definitely in favour of doing something (as I found it confusing, and in a way also found it has the potential to leak what could be sensitive information through command line contexts that are still lurking in the image with details about previous directory structures and commands).
I will try and and see how it impacts PharoLambda as a test example. Tim > On 14 Aug 2017, at 11:42, Guillermo Polito <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > I'm proposing a kind-of critical change that I believe is very good for the > health of the system: I want that the startup of the system runs in maximum > priority and becomes non-interruptable. > > Right now, when you save your image, the shutdown and startup are run in the > same priority than the process that triggered the save (usually the ui or the > command line, priority 40). This can cause lots of problems and race > conditions: processes with higher priorities can interrupt the > shutdown/startup and try to do something while the system is unstable. As a > side effect also, when you use extensively the command line, you start > stacking startup contexts from old sessions: > > ... > session 3 ctxt 4 <- This guy makes a save and a new session starts > session 3 ctxt 3 > session 3 ctxt 2 > session 3 ctxt 1 > session 2 ctxt 4 <- This guy makes a save and a new session starts > session 2 ctxt 3 > session 2 ctxt 2 > session 2 ctxt 1 > session 1 ctxt 4 <- This guy makes a save and a new session starts > session 1 ctxt 3 > session 1 ctxt 2 > session 1 ctxt 1 > > Old contexts are never collected, and the objects they referenced neither. > > To fix these two problems I propose to do every image save/session start in a > new process in maximum priority. That way, other process should not be able > to interrupt the startup process. Moreover, every session shutdown/startup > should happen in a new clean process, to avoid the session stacking. > > For normal users, this should have no side effect at all. This change will > have a good impact on people working on the debugger and the stack such as > fueling-out the stack because they will have a cleaner stack. > > There is however a side-effect/design point to consider: startup actions > should be quick to run. If a startup action requires to run a long-running > action such as starting a server or managing a command line action, that > should run in a separate process with lower priority (usually userPriority). > In other words, the startup action should create a new process managing its > action. > > If you want to review (and I'd be glad) > > Pull request: https://github.com/pharo-project/pharo/pull/198 > <https://github.com/pharo-project/pharo/pull/198> > Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 > <https://pharo.fogbugz.com/f/cases/20309> > Current validation going on: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-198/ > > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-198/> > > Guille > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr > <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13
