There is possibility where delay can be used during startup/shutdown. Library can clean resources which are managed by kind of pool which organizes timeout logic to enter synchronization monitor.
I checked Seamless which manages connections this way. But I not found any issue there. 2017-08-16 1:46 GMT+02:00 Guillermo Polito <[email protected]>: > > On Tue, Aug 15, 2017 at 3:25 PM, Ben Coman <[email protected]> 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. >> but then Eliot's suggestion to valueUnpreemptively may avoid that anyway. >> > > Why should a shutdown/startup use a delay? startup and shutdown should be > fast and not be blocked... If there is a delay on client code, it should > block a client thread, not a system thread... > > Moreover, I see a series of issues in having the delay process running in > higher priority than the startup. If I'm wrong, please correct me because > otherwise that means there is something I'm not getting. > > First, today the Delay scheduling process is being terminated on shutdown > and being re-initialized on startup. This means that even if a > shutdown/startup action tries to use a delay that will fail/block > indefinitely? > > Second, what happens with race conditions between the startup and the > delay process? If the shutdown is in the middle of terminating the delay > process and the delay process gets suddenly activated? > > stopTimerEventLoop > "Stop the timer event loop" > > timerEventLoop ifNotNil: [ timerEventLoop terminate ]. > timerEventLoop := nil. > > Maybe before terminating the timerEventLoop we need to suspend it? That > will at least atomically (primitive) remove the process from the ready list > and avoid it from being activated again, no? > > In any case, I see no good in letting a delay work on startup. That is far > too low level and the system would be in a far too unstable state to run > any code other than the startup itself. > > >> btw, what happens if an error occurs inside valueUnpreemptively? >> Does the normal priority debugger still get to run? >> >> cheers -ben >> >> On Mon, Aug 14, 2017 at 6:42 PM, 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. >>> >>> 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) >>> >>> Pull request: https://github.com/pharo-project/pharo/pull/198 >>> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 >>> Current validation going on: https://ci.inria.fr/pharo-ci-j >>> enkins2/job/Test%20pending%20pull%20request%20and%20branch%2 >>> 0Pipeline/view/change-requests/job/PR-198/ >>> >>> Guille >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> >>> Research Engineer >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr* >>> <http://www.cnrs.fr> >>> >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >
