On Mon, Aug 14, 2017 at 12:26 PM, Guillermo Polito < [email protected]> wrote:
> 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 :). > OK, good. > 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. > But to accomplish that you can simply do snapshot: save andQuit: quit ^[self launchSnapshot: save andQuit: quit] valueUnpreemptively right? > 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. > Not if encapsulated in valueUnpreemptively. > >> 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? > Ignore me. It's a non-issue since your proposal doesn't change what I thought it did. I thought you were proposing to start the system in a new process so that the state of the system didn't include the process that did the snapshot. Forgive the noise. > 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 > -- _,,,^..^,,,_ best, Eliot
