Hi Eliot, On Mon, Aug 14, 2017 at 9:07 PM, Eliot Miranda <[email protected]> wrote:
> 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. > Yes, we agree they are two different issues. > > 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. > But this behaviour is kept in my proposal :). Actually, what I propose is mainly changing the following: SessionManager >> #snapshot: save andQuit: shouldQuit -> renamed into #launchSnapshot: save andQuit: quit. and then define: snapshot: save andQuit: quit | isImageStarting wait | wait := Semaphore new. [ isImageStarting := self launchSnapshot: save andQuit: quit. wait signal ] forkAt: Processor highestPriority. wait wait. ^ isImageStarting Since the snapshot runs in max priority, users will be suspended until the startup is run in a safe manner. Moreover, I added a semaphore to handle the case where a process in max priority calls a snapshot. To me this proposal is cleaner than changing the priority of the current thread to the top priority, to then reset it to the old priority. > 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. > I did not get this one. Could you explain further? If you mean calling the command line handlers to install .st files for example, the command line handlers are called before anything else today in any case, as they are subscribed to the startup. So even if you saved your image from the world menu, the saved image will try to handle command line arguments on the next startup. > Further, the system stacking looks like a bug that should be addressed > elsewhere. Isn't it session management's responsibility for dropping older > sessions? > Yes, it's a different issue, I know. The current issue is that there is code that creates a snapshot as part of the startup. Starting up from a separate process is part of the solution for this (as a way to prevent it, whatever the users do). Thanks for looking into it :) Guille
