Hi Ben,

On Aug 15, 2017, at 6:25 AM, Ben Coman <btc@openinworld.com> wrote:

In case any of the shutdown/startup scripts use a delay, now or in the future,  
I'd first try at    highestPriority-1 to avoid influence on the DelayScheduler.

+1.  In fact I'd raise it to no more than lowIOPriority - 1.


but then Eliot's suggestion to valueUnpreemptively may avoid that anyway.

It does not.


btw, what happens if an error occurs inside valueUnpreemptively?
Does the normal priority debugger still get to run?

Once the notifier is opened the process is suspended.  So startup will not complete, just as is the case now.  But the exception is logged, so it's no longer invisible.

BTW, on a related note, on snapshot, the primitive should not do a GC.  Instead, the system should go a GC and allow any resulting finalization complete before the snapshot and well before the quit.  Consider a buffered file that is flushed on finalization.  This must happen before the snapshot.  The GC in the snapshot is fine for ensuring the snapshot file is compact but very wrong for adding things to the finalization queue.

cheers -ben

On Mon, Aug 14, 2017 at 6:42 PM, 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.

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