Hi Guille,
On Mon, Aug 14, 2017 at 3:42 AM, Guillermo Polito <[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.
>
I think you're mixing up two things here. One is wanting to make
startup/shutdown uninterruptible by raising the priority of the process
that does startup & shutdown. The other is starting the system with a new
process.
I don't want to express an opinion on the former, but I think the latter is
not a good idea. One important feature of Smalltalks up until your
proposed change is that snapshotAs:thenQuit: can be sent anywhere, causes a
snapshot and resumes execution after the send of snapshotAs:thenQuit: once
the internals of snapshotAs:thenQuit: have rebooted the system. This is
really useful:
- applications can snapshot the system as they choose for checkpointing, etc
- for VM debugging one can execute the snapshotAs:thenQuit: anywhere (for
example inside an inspector where self is bound to some interesting object)
and follow it by whatever code one chooses, e.g. to provoked a bug. For
example
Smalltalk snapshotAs: 'foo' thenQuit: true.
self doSomethingTerminal
Your change will break this and make it much harder to debug certain
things. One will be able to use the file-in scheme, but this implies the
system will always run the compiler first, and one may not want that.
Further, the system stacking looks like a bug that should be addressed
elsewhere. Isn't it session management's responsibility for dropping older
sessions?
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>
>
--
_,,,^..^,,,_
best, Eliot
