[squeak-dev] Re: #ensure: What would you expect?

Eliot Miranda eliot.miranda at gmail.com
Fri Dec 2 18:56:14 UTC 2011


On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20111202/e9c8a89c/attachment.htm


More information about the Squeak-dev mailing list