Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect?
On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab@gmx.de> wrote:
There is only one possibly correct answer which is raising BlockCannotReturn, because we're trying to return while we're in the midst of returning already, so there is no place to return to. That answer is implemented by the attached change set.
BTW, the code duplication between ContextPart>>restart ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate bothers me greatly. The change set only fixes one of these locations (the one triggered by your problem statement) but having such critical code duplicated all over the places can't be good. Any takers?
The first thing is a good set of tests. Do we have some of them? Clearly we don't have them for this case. What's the scope of the tests? The second thing I find related is that I find ContextPart>jump incomprehensible and worrying. Using simulation machinery to advance execution just seems wrong with me and yet this code is used in process termination (via runUntilErrorOrReturnFrom:) and in exception handling (via ContextPart>restart). ContextPart>jump is extremely complex and slow and buggy (I recently ( eem 11/16/2011 10:58) found and fixed a bad bug in runUntilErrorOrReturnFrom: that was causing too much peeling back of the stack in exception delivery when trying to advance a process to a particular point suitable for presenting to the user. If we could simplify this code that would be a relief to me :) The third thing that is related is that if a process is terminated from a different process, then unwinds execute in the context of the process that initiated the termination, not the process being terminated. The fourth thing that is related in my mind is that Cog supports a much faster Mutex which is in use in OpenQwaq and could be ported to Squeak and Pharo. But it needs some work on process termination, to avoid losing a signal when a process is terminated while in a critical section on the mutex. This is related because fixing this requires some work on unwind implementation. I think all of these need addressing, but they shouldn't be conflated. I'm just writing them down here so they don't get forgotten. cheers, Eliot
Cheers, - Andreas
On 12/2/2011 15:18, Tobias Pape wrote:
Dear All,
given the following class:
Object subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Foo'! a self b: [^ 1].! !
b: aBlock
[self c: aBlock] ensure: [^ 2].
c: aBlock
aBlock value. ^ 3
And you would do
Foo new a
what would you expect?
I am very curious. Please, first guess, then execute.
Best -Tobias
-- best, Eliot
I have *NO* idea whether this is relevant or helpful, but just in case... If memory serves, Dolphin makes a point of getting ensured blocks to run on the correct process by (perhaps conditionally) suspending and re-starting the offending Process instance. HTH. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda@gmail.com] Sent: Friday, December 02, 2011 1:56 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect? On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab@gmx.de<mailto:andreas.raab@gmx.de>> wrote: There is only one possibly correct answer which is raising BlockCannotReturn, because we're trying to return while we're in the midst of returning already, so there is no place to return to. That answer is implemented by the attached change set. BTW, the code duplication between ContextPart>>restart ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate bothers me greatly. The change set only fixes one of these locations (the one triggered by your problem statement) but having such critical code duplicated all over the places can't be good. Any takers? The first thing is a good set of tests. Do we have some of them? Clearly we don't have them for this case. What's the scope of the tests? The second thing I find related is that I find ContextPart>jump incomprehensible and worrying. Using simulation machinery to advance execution just seems wrong with me and yet this code is used in process termination (via runUntilErrorOrReturnFrom:) and in exception handling (via ContextPart>restart). ContextPart>jump is extremely complex and slow and buggy (I recently ( eem 11/16/2011 10:58) found and fixed a bad bug in runUntilErrorOrReturnFrom: that was causing too much peeling back of the stack in exception delivery when trying to advance a process to a particular point suitable for presenting to the user. If we could simplify this code that would be a relief to me :) The third thing that is related is that if a process is terminated from a different process, then unwinds execute in the context of the process that initiated the termination, not the process being terminated. The fourth thing that is related in my mind is that Cog supports a much faster Mutex which is in use in OpenQwaq and could be ported to Squeak and Pharo. But it needs some work on process termination, to avoid losing a signal when a process is terminated while in a critical section on the mutex. This is related because fixing this requires some work on unwind implementation. I think all of these need addressing, but they shouldn't be conflated. I'm just writing them down here so they don't get forgotten. cheers, Eliot Cheers, - Andreas On 12/2/2011 15:18, Tobias Pape wrote: Dear All, given the following class: Object subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Foo'! a self b: [^ 1].! ! b: aBlock [self c: aBlock] ensure: [^ 2]. c: aBlock aBlock value. ^ 3 And you would do Foo new a what would you expect? I am very curious. Please, first guess, then execute. Best -Tobias -- best, Eliot
participants (2)
-
Eliot Miranda -
Schwab,Wilhelm K