- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the process actually on the list... > > I just test it in workspace. > sema := Semaphore new. > p := [sema wait] fork. > p suspend. > p suspendingList == nil > sema asArray isEmpty > Of course, that's something entirely different... if you do what I actually do in the modified terminate; sema := Semaphore new. p := [sema wait ] newProcess. p resume. 1 second wait. list := p suspend. "this list is (re)assigned to myList in terminate" list == nil list == sema You should get different answers. Cheers, Henry

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the > process actually on the list... > I just test it in workspace. sema := Semaphore new. p := [sema wait] fork. p suspend. p suspendingList == nil sema asArray isEmpty

Jan. 8, 2016

Re: [Pharo-dev] Changing performance balance between CPU & non-volatile storage

by Ben Coman

On Fri, Jan 8, 2016 at 9:17 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 07-01-16 20:07, Ben Coman wrote: >> >> An enlightening article (if a bit long). I wonder how non-volatile >> storage being faster than a CPU might affect Pharo systems. Perhaps >> the importance of migrating between live and backup Images gains in >> importance to backups via files. > > > I'm not sure what to think about it. I find it an rather vague and badly > written article. 100K iops is not close to saturating what a CPU core can > process. The problem is the communication and the article does a really good > job at confusing me about that. Further, commercial pricing is value based, > not cost. > > Stephan Yeah, I think I'll have to retract that about being enlightening, rather just a faÃ§ade of enlightenment. Many of the follow up comments on slashdot hit criticised it along the same lines and that its point of view is that of vendors selling fast-nvram. I probably shouldn't have posted it. Sorry for the noise. cheers -ben

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 08 Jan 2016, at 3:07 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Yes. When process suspend called during termination process has no more semaphore as suspendingList Which is why in terminate I do myList := self suspend. So the semaphore *should* still be the suspendingList, just without the process actually on the list... Seems to me something strange happens between setting activeProcess using execute:onBehalfOf: and when it reaches the ifCurtailed block, at that point the terminating thread is no longer the "active" process. Cheers, Henry > > 2016-01-08 14:56 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Ugh, there's a bug with the Processor activeProcess suspendingList, I only checked in the case where it *should* signal. > Take it as an inspiration :) > > Cheers, > Henry > >> On 08 Jan 2016, at 2:40 , Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument. >> Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if the (suspended) terminating thread they started executing on, is still the active process. (Which, arguably, should be done anyways) >> >> Cheers, >> Henry >> >> <SignalUsingUnwindMachinery.cs> >> >> >> "This runs on UI thread, pri 40" >> waiter := Semaphore new. >> waiter2 := Semaphore new. >> lock := Semaphore forMutualExclusion. >> >> proc := [lock critical2: [ Transcript crShow: '1 start'. >> waiter wait. >> Transcript crShow: '1 done'.]] newProcess. >> proc priority: 70. >> proc resume. >> >> proc2 := [lock critical2: [ Transcript crShow: '2 start'. >> waiter2 wait. >> Transcript crShow: '2 done'. ]] newProcess. >> proc2 priority: 15. >> proc2 resume. >> >> "Yield for proc2 so it gets to waiting on lock" >> 1 second wait. >> "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" >> waiter signal. >> Processor yield. >> "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" >> proc2 terminate. >> "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." >> (lock instVarNamed: 'excessSignals') 1 >>> On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage >>> >>> 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >>> >>> 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: >>> >>> I'm not qualified to judge, but is sounds okay. I have an alternative >>> proposal to consider that hopefully might remove Semaphore handling >>> completely from Process>>terminate. >>> >>> What if we have a wait primitive that instead of returning itself >>> (i.e. a Semaphore), it always returns true. Then if the process is >>> terminated while the primitive is waiting, before it consumes a >>> signal, the assignment to signalConsumed never occurs. Then we >>> have... >>> >>> critical: mutuallyExcludedBlock >>> signalConsumed := false. >>> [ >>> signalConsumed := self primWaitSucceeded. >>> blockValue := mutuallyExcludedBlock value >>> ] ensure: [ signalConsumed ifTrue: [self signal] ]. >>> ^blockValue >>> >>> It *feels* more atomic. Someone knowledgeable with the vm would need >>> to advise whether after the primitive wakes up and consumes a signal, >>> the assignment into signalConsumed can be guaranteed to occur before >>> the process gets a chance to terminate, even if the primitive needs to >>> directly poke the value into signalConsumed. >>> >>> To me it is better too. But it requires changes in VM primitive which I'm can't provide. >>> So I will implement my idea. Do you ok with the name #waitIfInterrupted? >>> >> > >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Yes. When process suspend called during termination process has no more semaphore as suspendingList 2016-01-08 14:56 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Ugh, there's a bug with the Processor activeProcess suspendingList, I only > checked in the case where it *should* signal. > Take it as an inspiration :) > > Cheers, > Henry > > On 08 Jan 2016, at 2:40 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > Here's an alternative implementation, which, instead of checking for the > new method name, hooks into the existing unwind machinery to execute the > waitIfCurtailed: argument. > Which removes the special case from Process >> #terminate, but at the > added cost that in-progress unwinds are executed as if the (suspended) > terminating thread they started executing on, is still the active process. > (Which, arguably, should be done anyways) > > Cheers, > Henry > > <SignalUsingUnwindMachinery.cs> > > > "This runs on UI thread, pri 40" > waiter := Semaphore new. > waiter2 := Semaphore new. > lock := Semaphore forMutualExclusion. > > proc := [lock critical2: [ Transcript crShow: '1 start'. > waiter wait. > Transcript crShow: '1 done'.]] newProcess. > proc priority: 70. > proc resume. > > proc2 := [lock critical2: [ Transcript crShow: '2 start'. > waiter2 wait. > Transcript crShow: '2 done'. ]] newProcess. > proc2 priority: 15. > proc2 resume. > > "Yield for proc2 so it gets to waiting on lock" > 1 second wait. > "Signal waiter and yield, causing proc1 to run, and release the lock. lock > will then remove proc2 from waiting list" > waiter signal. > Processor yield. > "We have a higher pri than proc2, and will resume execution here before > proc2 has chance to run" > proc2 terminate. > "proc2 has been curtailed before running, thus ifCurtailed: guard is still > on stack and will be run as part of termination." > (lock instVarNamed: 'excessSignals') 1 > > On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Ok. slice 17340 > <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> > in inbox. It is only touches current #critical: implementation. It is not > about deprecation wrong semaphore usage > > 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> I'm not qualified to judge, but is sounds okay. I have an alternative >>> proposal to consider that hopefully might remove Semaphore handling >>> completely from Process>>terminate. >>> >>> What if we have a wait primitive that instead of returning itself >>> (i.e. a Semaphore), it always returns true. Then if the process is >>> terminated while the primitive is waiting, before it consumes a >>> signal, the assignment to signalConsumed never occurs. Then we >>> have... >>> >>> critical: mutuallyExcludedBlock >>> signalConsumed := false. >>> [ >>> signalConsumed := self primWaitSucceeded. >>> blockValue := mutuallyExcludedBlock value >>> ] ensure: [ signalConsumed ifTrue: [self signal] ]. >>> ^blockValue >>> >>> It *feels* more atomic. Someone knowledgeable with the vm would need >>> to advise whether after the primitive wakes up and consumes a signal, >>> the assignment into signalConsumed can be guaranteed to occur before >>> the process gets a chance to terminate, even if the primitive needs to >>> directly poke the value into signalConsumed. >> >> >> To me it is better too. But it requires changes in VM primitive which I'm >> can't provide. >> So I will implement my idea. Do you ok with the name #waitIfInterrupted? >> > > > >

Jan. 8, 2016

Re: [Pharo-dev] Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Marcus Denker

Hello, This is now integrated. > On 05 Jan 2016, at 16:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > yes, > > this is fixed by > > https://pharo.fogbugz.com/f/cases/17276/Semantic-Analysis-needs-refactoring > > I am now back from holidays and will review/intergrate this soon. > > >> On 05 Jan 2016, at 16:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I am seeing the following very annoying error in 50511 spur. >> >> Open a Playground, >> type [ (both open en close are inserted, with the cursor in-between), >> type : (to start a block arg), >> boom: >> >> RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance >> OCASTClosureAnalyzer>>changeVariableClass: >> OCASTClosureAnalyzer>>visitArgumentNode: >> [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >> OrderedCollection>>do: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >> OCASTClosureAnalyzer>>visitBlockNode: >> RBBlockNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >> OrderedCollection>>do: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >> RBSequenceNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTClosureAnalyzer>>visitMethodNode: >> RBMethodNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>analyze: >> RBMethodNode>>doSemanticAnalysis >> RBBlockNode(RBProgramNode)>>doSemanticAnalysis >> RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: >> [ self privateStyle: text. >> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. >> view ifNotNil: [ view stylerStyledInBackground: text ] ] >> forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: >> [ self value. >> Processor terminateActive ] in BlockClosure>>newProcess >> >> Has this already been reported ? >> >> It makes the image almost unusable... >> >> Sven >> >> >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

Ugh, there's a bug with the Processor activeProcess suspendingList, I only checked in the case where it *should* signal. Take it as an inspiration :) Cheers, Henry > On 08 Jan 2016, at 2:40 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument. > Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if the (suspended) terminating thread they started executing on, is still the active process. (Which, arguably, should be done anyways) > > Cheers, > Henry > > <SignalUsingUnwindMachinery.cs> > > > "This runs on UI thread, pri 40" > waiter := Semaphore new. > waiter2 := Semaphore new. > lock := Semaphore forMutualExclusion. > > proc := [lock critical2: [ Transcript crShow: '1 start'. > waiter wait. > Transcript crShow: '1 done'.]] newProcess. > proc priority: 70. > proc resume. > > proc2 := [lock critical2: [ Transcript crShow: '2 start'. > waiter2 wait. > Transcript crShow: '2 done'. ]] newProcess. > proc2 priority: 15. > proc2 resume. > > "Yield for proc2 so it gets to waiting on lock" > 1 second wait. > "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" > waiter signal. > Processor yield. > "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" > proc2 terminate. > "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." > (lock instVarNamed: 'excessSignals') 1 >> On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage >> >> 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >> 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: >> >> I'm not qualified to judge, but is sounds okay. I have an alternative >> proposal to consider that hopefully might remove Semaphore handling >> completely from Process>>terminate. >> >> What if we have a wait primitive that instead of returning itself >> (i.e. a Semaphore), it always returns true. Then if the process is >> terminated while the primitive is waiting, before it consumes a >> signal, the assignment to signalConsumed never occurs. Then we >> have... >> >> critical: mutuallyExcludedBlock >> signalConsumed := false. >> [ >> signalConsumed := self primWaitSucceeded. >> blockValue := mutuallyExcludedBlock value >> ] ensure: [ signalConsumed ifTrue: [self signal] ]. >> ^blockValue >> >> It *feels* more atomic. Someone knowledgeable with the vm would need >> to advise whether after the primitive wakes up and consumes a signal, >> the assignment into signalConsumed can be guaranteed to occur before >> the process gets a chance to terminate, even if the primitive needs to >> directly poke the value into signalConsumed. >> >> To me it is better too. But it requires changes in VM primitive which I'm can't provide. >> So I will implement my idea. Do you ok with the name #waitIfInterrupted? >> >

Jan. 8, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50518 Home: https://github.com/pharo-project/pharo-core

Jan. 8, 2016

[pharo-project/pharo-core] 54e47e: 50518

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 54e47eec2c5cdc081b4a8e94428e656ca2489211 https://github.com/pharo-project/pharo-core/commit/54e47eec2c5cdc081b4a8e94… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-08 (Fri, 08 Jan 2016) Changed paths: A AST-Core.package/RBArgumentNode.class/instance/converting/adaptToSemanticNode.st A AST-Core.package/RBParseErrorNode.class/instance/converting/adaptToSemanticNode.st A AST-Core.package/RBVariableNode.class/instance/converting/adaptToSemanticNode.st R OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/variables/changeVariableClass_.st M OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitArgumentNode_.st M OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitVariableNode_.st A OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/declareArgumentNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/declareVariableNode_.st A OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/declareVariableNode_as_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitBlockNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitInlinedBlockNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitMethodNode_.st R OpalCompiler-Core.package/OCAbstractLocalVariable.class/instance/read%2Fwrite usage/isArg.st M OpalCompiler-Core.package/OCAbstractLocalVariable.class/instance/read%2Fwrite usage/isUninitialized.st R OpalCompiler-Core.package/OCAbstractLocalVariable.class/instance/read%2Fwrite usage/markArg.st M OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/initialization/initialize.st M OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/temp vars/addTemp_.st A OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/temp vars/addTemp_withName_.st A OpalCompiler-Core.package/OCAbstractVariable.class/class/accessing/semanticNodeClass.st R OpalCompiler-Core.package/OCAbstractVariable.class/instance/accessing/asString.st R OpalCompiler-Core.package/OCAbstractVariable.class/instance/accessing/isArg.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/converting/asString.st M OpalCompiler-Core.package/OCAbstractVariable.class/instance/read%2Fwrite usage/isRead.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/testing/isArg.st A OpalCompiler-Core.package/OCArgumentVariable.class/README.md A OpalCompiler-Core.package/OCArgumentVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCArgumentVariable.class/definition.st A OpalCompiler-Core.package/OCArgumentVariable.class/instance/testing/isArg.st A OpalCompiler-Core.package/OCArgumentVariable.class/instance/testing/isUninitialized.st A OpalCompiler-Core.package/OCArgumentVariable.class/instance/testing/isWritable.st M OpalCompiler-Core.package/OCInstanceScope.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCLiteralVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCSelfVariable.class/README.md A OpalCompiler-Core.package/OCSelfVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCSelfVariable.class/definition.st A OpalCompiler-Core.package/OCSelfVariable.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCSelfVariable.class/instance/testing/isSelf.st A OpalCompiler-Core.package/OCSlotVariable.class/class/accessing/semanticNodeClass.st M OpalCompiler-Core.package/OCSpecialVariable.class/instance/emitting/emitValue_.st R OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isContext.st R OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isSelf.st R OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isSuper.st A OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isThisContext.st A OpalCompiler-Core.package/OCSuperVariable.class/README.md A OpalCompiler-Core.package/OCSuperVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCSuperVariable.class/definition.st A OpalCompiler-Core.package/OCSuperVariable.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCSuperVariable.class/instance/testing/isSuper.st A OpalCompiler-Core.package/OCTempVariable.class/class/accessing/semanticNodeClass.st R OpalCompiler-Core.package/OCTempVariable.class/instance/testing/isWritable.st A OpalCompiler-Core.package/OCThisContextVariable.class/README.md A OpalCompiler-Core.package/OCThisContextVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCThisContextVariable.class/definition.st A OpalCompiler-Core.package/OCThisContextVariable.class/instance/emitting/emitValue_.st A OpalCompiler-Core.package/OCThisContextVariable.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCThisContextVariable.class/instance/testing/isThisContext.st A OpalCompiler-Core.package/OCUndeclaredVariable.class/class/accessing/semanticNodeClass.st M OpalCompiler-Tests.package/OCASTCheckerTest.class/instance/testing - variables/testExampleThisContext.st M Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitMethodNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50517.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50518.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50517.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50518.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50518 17276 Semantic Analysis needs refactoring https://pharo.fogbugz.com/f/cases/17276 http://files.pharo.org/image/50/50518.zip

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument. Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if the (suspended) terminating thread they started executing on, is still the active process. (Which, arguably, should be done anyways) Cheers, Henry "This runs on UI thread, pri 40" waiter := Semaphore new. waiter2 := Semaphore new. lock := Semaphore forMutualExclusion. proc := [lock critical2: [ Transcript crShow: '1 start'. waiter wait. Transcript crShow: '1 done'.]] newProcess. proc priority: 70. proc resume. proc2 := [lock critical2: [ Transcript crShow: '2 start'. waiter2 wait. Transcript crShow: '2 done'. ]] newProcess. proc2 priority: 15. proc2 resume. "Yield for proc2 so it gets to waiting on lock" 1 second wait. "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" waiter signal. Processor yield. "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" proc2 terminate. "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." (lock instVarNamed: 'excessSignals') 1 > On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage > > 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: > > I'm not qualified to judge, but is sounds okay. I have an alternative > proposal to consider that hopefully might remove Semaphore handling > completely from Process>>terminate. > > What if we have a wait primitive that instead of returning itself > (i.e. a Semaphore), it always returns true. Then if the process is > terminated while the primitive is waiting, before it consumes a > signal, the assignment to signalConsumed never occurs. Then we > have... > > critical: mutuallyExcludedBlock > signalConsumed := false. > [ > signalConsumed := self primWaitSucceeded. > blockValue := mutuallyExcludedBlock value > ] ensure: [ signalConsumed ifTrue: [self signal] ]. > ^blockValue > > It *feels* more atomic. Someone knowledgeable with the vm would need > to advise whether after the primitive wakes up and consumes a signal, > the assignment into signalConsumed can be guaranteed to occur before > the process gets a chance to terminate, even if the primitive needs to > directly poke the value into signalConsumed. > > To me it is better too. But it requires changes in VM primitive which I'm can't provide. > So I will implement my idea. Do you ok with the name #waitIfInterrupted? >

Jan. 8, 2016