On 26 July 2018 at 00:46, Johan Brichau <johan@inceptive.be> wrote:

...

Hi,

I ran into a freeze issue when trying to save and/or quit an image after loading Seaside3 and Zinc (not an infrequent combination :)

The cause seems to be that terminating processes in a `shutDown` handler (called on image shutdown / snapshot) leads to a deadlock (somewhere). Both Comet and Zinc will send #terminate to a process when an image is quit or saved. If I disable one of those, the deadlock does not occur.

I managed to reconstruct the issue with a simple example, attached.

The attached Freeze class creates two processes (that loop with a Delay>>wait inside) in the `startUp` method (on image start). These processes are terminated by the shutdown method (called on image quit/save). However, when you try to quit and/or save the image, you will experience an image freeze.

I’m not familiar with the process scheduler, or anything else in this context… so help would be appreciated while I try to dive further into it :)

To reproduce: just file in the attached file in a Pharo7 image and try to quit. For reference, System Reporter output for my configuration.

Any ideas?

Cheers Johan

On Thu, 26 Jul 2018 at 19:06, Ben Coman <btc@openinworld.com> wrote:

I don't have a total answer, but can confirm the problem and help characterize it. First, great test-snippet. Really nice and concise.

On Windows it indeed freezes my Pharo 7 image when saving the image.

It doesn't freeze Pharo 6.

It doesn't freeze if the test-processes are not terminated.

It doesn't freeze if the shutdown code runs at a lower priority that the test-processes. i.e. it works with these added lines... shutDown: quitting "+" |restorePriority| "+" restorePriority := Processor activeProcess priority. "+" Processor activeProcess priority: 15. Process1 ifNotNil:[ Process1 terminate ]. Process2 ifNotNil: [Process2 terminate ]. "+" Processor activeProcess priority: restorePriority. Process1 := Process2 := nil

Does that help someone else identify the relevant changes between Pharo 6 & 7 to explain the behaviour in more depth.

cheers -ben

This was being worked on in https://pharo.fogbugz.com/f/cases/22284/Freeze-during-startup

From recent discussion Vincent, I believe I've got my head fully around this...

IIUC part of the shutDown/startUp was being run at highestPriority. So your case boiled down to... |process1 process2| Delay delaySchedulerClass: DelaySpinScheduler. "default < build 1273" processA := [ (Delay forSeconds: 10) wait ] forkAt: 20 named: 'processA'. processB := [ (Delay forSeconds: 10) wait ] forkAt: 20 named: 'processB'. 1 second wait. [ processA terminate. processB terminate. "image locked here" ] forkAt: Processor highestPriority. The freeze is due to the #terminate causing the curtailed block in Delay>>wait being run at highestPriority. Delay>>wait self schedule. [delaySemaphore wait] ifCurtailed: [self unschedule]. The first termination (Process A) fills the transfer variable /finishedDelay/ in DelaySpinScheduler>>unschedule: which is normally cleared by "timingSemaphore signal" waking up #handleTimerEvent: running at highestPriority. But with #unschedule: at highestPriority, co-operative scheduling within priorities instead continues execution with the second termination (Process B) which finds /finishedDelay/ still filled and spins forever with no chance of #handleTimerEvent: running to clear the transfer variable. The following instrumentation helps observe this... DelayExperimentalScheduler>>unschedule: aDelay finishedDelay == nil ifTrue: [ finishedDelay := aDelay. "...and this assignment" timingSemaphore signal. ] ifFalse: [ |context| Transcript crShow: Processor activeProcess name, ' finishedDelay not nil'. context := thisContext. [ context = nil ] whileFalse: [ Transcript crShow: ' <-- ', context printString. context := context sender ]]. which then using "Delay delaySchedulerClass: DelayExperimentalSpinScheduler" for the boiled-down-case produces... processB finishedDelay not nil <-- DelayExperimentalSpinScheduler>>unschedule: <-- Delay>>unschedule <-- [ self unschedule ] in Delay>>wait <-- Context>>resume:through: <-- BlockClosure>>ifCurtailed: <-- Delay>>wait <-- [ (Delay forSeconds: 10) wait ] in UndefinedObject>>DoIt <-- BlockClosure>>on:do: <-- BlockClosure>>ensure: <-- [ self value. Processor terminateActive ] in BlockClosure>>newProcess # POSSIBLE FIXES 1. Adding a "Processor yield" like this... DelaySpinScheduler>>unschedule: aDelay [ finishedDelay == nil ifTrue: [ finishedDelay := aDelay. timingSemaphore signal. finishedDelay ifNotNil: [ Processor yield ]. ^true. ]. true. ] whileTrue. 2. Change the #signal semantics to immediately activate a signaled process when signalled/signalling priorities are the same. Maybe like this... StackInterpreter>>resume: aProcess preemptedYieldingIf: yieldImplicitly - "Make aProcess runnable and if its priority is higher than that of the current process, preempt the current process. " + "Make aProcess runnable and if its priority is the same or higher than that of the current process, preempt the current process." | activeProc activePriority newPriority | <inline: false> activeProc := self activeProcess. activePriority := self quickFetchInteger: PriorityIndex ofObject: activeProc. newPriority := self quickFetchInteger: PriorityIndex ofObject: aProcess. - newPriority <= activePriority ifTrue: + newPriority < activePriority ifTrue: [self putToSleep: aProcess yieldingIf: true. ^false]. self putToSleep: activeProc yieldingIf: yieldImplicitly. self transferTo: aProcess. ^true 3. Switching to DelaySemaphoreScheduler which suspends the activeProcess when the transfer variable is not empty. This is default in the latest builds. @Vincent, revising what I said elsewhere that the delay scheduler must be the only process running at highestPriority, I've realised that was an assumption I'd held without detailed consideration. Perhaps that is over constrained. Now understanding better the cause of the freeze, it only affects the spin-scheduler due to its busy-loop in the methods I'd considered only ran at user-priority. So other processes running at highestPriority is probably okay, as long as they have no busy loops. cheers -ben