Hi Guille,

On Mon, Aug 14, 2017 at 3:42 AM, Guillermo Polito <guillermopolito@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.

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)


Guille

--

������

Guille Polito


Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr



Web: http://guillep.github.io

Phone: +33 06 52 70 66 13



--
_,,,^..^,,,_
best,��Eliot