[Pharo-dev] Issue 20309 - Startup should run always in a fresh process
stepharo.self at gmail.com
Mon Aug 14 12:59:48 EDT 2017
thanks for raising this point. I will wait a bit that other people comment
on it since it is a crucial point.
On Mon, Aug 14, 2017 at 4:47 PM, Tim Mackinnon <tim at testit.works> wrote:
> 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.
> On 14 Aug 2017, at 11:42, Guillermo Polito <guillermopolito at gmail.com>
> 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
> 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
> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309
> Current validation going on: https://ci.inria.fr/pharo-ci-
> Guille Polito
> Research Engineer
> French National Center for Scientific Research - *http://www.cnrs.fr*
> *Web:* *http://guillep.github.io* <http://guillep.github.io/>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev