Thanks for this discussion! It will improve Guille proposal and Pharo :) I'm happy! And learning things. (ok I should prepare my lectures instead of reading. I guess that I will have to use pomodoro techniques to force me to work :)
Stef On Mon, Aug 14, 2017 at 9:48 PM, Eliot Miranda <[email protected]> wrote: > > > 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
