janko open an issue with such cases so that we do not forget it. Stef
On Apr 21, 2012, at 2:54 PM, Janko Mivšek wrote: > Hi guys, > > This code reproduces the blockade in fresh 1.4 OneClick (with or without > Transcript window open): > > [ > (Delay forSeconds: 5) wait. > SmalltalkImage current saveSession. > ] forkAt: Processor userBackgroundPriority > > Note that fork on default priority does not block while on user > background priority it blocks. It does not always block immediately > (sometimes yes sometimes not) but it after image restart it is always > blocked. > > But if you periodically write to Transcript from process on user > background priority, it does not block, even if you heavily browse > around, write to transcript, do manual snapshot: > > [ [true] whileTrue: > [(Delay forMilliseconds: 500) wait. > Transcript show: '.tst.'] > ] forkAt: Processor userBackgroundPriority > > So, it seems not only thread-safe Transcript but something with snapshot > (from a background priority, why?) is in play here. > > SmalltalkImage>>snapshot:andQuit: , shouldn’t run it on highest priority > to block all other processes during the preparation for snapshot? > > Hope this helps a bit more > Janko > > > > Dne 21. 04. 2012 11:48, piše Igor Stasenko: >> So, this is related to thread-safe transcript code.. >> which using semaphore to synchronize access to transcript stream. >> I guess what happens is that a semaphore is blocked in another >> process, but for some strange reason never released. This leads to >> situation, that any other process which will attempt to write to >> transcript will be blocked as well.. forever. > > Why is input not blocked immediately but after image restart? > > > More investigation: > > > 1. correction: image blocks in any case after restart, regardless if > there is additional writing to Transcript or not. Snapshot namely writes > to Transcript by itself and this is enough to block. > > 1. even if Transcript is closed the image blocks after restart > > This simulated snapshot from the background does NOT block after restart: > > [ > (Delay forSeconds: 5) wait. > SmalltalkImage current saveSession. > ] fork > > This one also not: > > [ | elapsed | > (Delay forSeconds: 5) wait. > elapsed := Time millisecondsToRun: > [SmalltalkImage current saveSession]. > Transcript show: ' in ', (elapsed // 1000) printString, 's '. > ] forkAt: Processor userBackgroundPriority > > > > > > >> >> 2012/4/21 Janko Mivšek <[email protected]>: >>> Hi guys, >>> >>> It seems that writing to Transcript from background process causes my >>> freeze after restart. And yes, I have Transcript window open. >>> >>> This is a code snippet in question: >>> >>> AIDASite class>>imageSnapshot >>> ... >>> elapsed := Time millisecondsToRun: >>> [SmalltalkImage current saveSession]. >>> Transcript show: ' in ', (elapsed // 1000) printString, 's '. >>> >>> >>> If I comment out the last line, snapshot doesn't block the image after >>> restart. >>> >>> This is not necessary 1.4 specific problem, because I noticed similar >>> problem in 1.3 also. Just that on 1.3 input freezes immediately while on >>> 1.4 it freezes after restart. >>> >>> Let me investigate a bit further, what if Transcript window is not open? >>> >>> Best regards >>> Janko >>> >>> >>> >>> Dne 20. 04. 2012 21:42, piše Stéphane Ducasse: >>>> Ok may be nautilus bug. It should be different than janko problem. >>>> >>>> Stef >>>> >>>> On Apr 20, 2012, at 9:39 PM, Sean P. DeNigris wrote: >>>> >>>>> >>>>> Stéphane Ducasse wrote >>>>>> >>>>>> on which os? >>>>>> >>>>> >>>>> Mac Lion 10.7.3 >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Unresponsive-1-4-image-tp4574693p4575049.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko Mivšek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko Mivšek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >
