[Pharo-dev] Issue 20309 - Startup should run always in a fresh process

Stephane Ducasse stepharo.self at gmail.com
Mon Aug 14 12:59:48 EDT 2017


Hi guille

thanks for raising this point. I will wait a bit that other people comment
on it since it is a crucial point.

Stef

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.
>
> Tim
>
> On 14 Aug 2017, at 11:42, Guillermo Polito <guillermopolito at gmail.com>
> 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
> Fogbugz issue: 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/
>
> 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 <+33%206%2052%2070%2066%2013>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170814/862c2d7d/attachment.html>


More information about the Pharo-dev mailing list