Smalltalk › Squeak › Squeak VM

Re: [Pharo-project] BlockClosure>>ensure: implementation

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Eliot Miranda-2

Re: [Pharo-project] BlockClosure>>ensure: implementation

On Mon, Oct 22, 2012 at 2:17 AM, Clément Bera <[hidden email]> wrote:

Hello,

I don't understand something on BlockClosure>>ensure:. Why does it use 'self valueNoContextSwitch' and not 'self value' ? In which case is there an issue ?

Prior to my closure implementation BlockContext>>value[:value:*] was not a context switch point. So to preserve the threading semantics of ensure: we implemented ensure: in terms of BlockClosure>>valueNoContextSwitch, which is not a context-switch point, as opposed to BlockClosure>>value[:value:*]. The context switch points in the VM are non-primitive sends (or failing primitives, i.e. full method activation), backward branches, the Process primitives suspend, resume, signal and wait (and CrtiticalSection/Mutex enter and exit) and block evaluation.

Thank you for any answers

BlockClosure>>ensure: is implemented this way :

ensure: aBlock
"Evaluate a termination block after evaluating the receiver, regardless of
whether the receiver's evaluation completes. N.B. This method is *not*
implemented as a primitive. Primitive 198 always fails. The VM uses prim
198 in a context's method as the mark for an ensure:/ifCurtailed: activation."

| complete returnValue |
<primitive: 198>
returnValue := self valueNoContextSwitch.
complete ifNil:[
complete := true.
aBlock value.
].
^ returnValue

--
best,

Eliot

Igor Stasenko

Re: [Pharo-project] BlockClosure>>ensure: implementation

On 24 October 2012 00:57, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Mon, Oct 22, 2012 at 2:17 AM, Clément Bera <[hidden email]> wrote:
>>
>> Hello,
>>
>> I don't understand something on BlockClosure>>ensure:. Why does it use 'self valueNoContextSwitch' and not 'self value' ? In which case is there an issue ?
>
>
> Prior to my closure implementation BlockContext>>value[:value:*] was not a context switch point. So to preserve the threading semantics of ensure: we implemented ensure: in terms of BlockClosure>>valueNoContextSwitch, which is not a context-switch point, as opposed to BlockClosure>>value[:value:*]. The context switch points in the VM are non-primitive sends (or failing primitives, i.e. full method activation), backward branches, the Process primitives suspend, resume, signal and wait (and CrtiticalSection/Mutex enter and exit) and block evaluation.
>

Hmm.. your response puzzles me even more.

just simple example to show a controversy:

[ do something ] ensure: [ semaphore signal. anotherSemaphore wait ].

I think that semantics of ensure should be:
- same as #value, but evaluate additional "ensure" block prior return
point , be it normal return or stack unwinding (non-local return or
process termination).

Anything else, like scheduler interference, which may preempt current
process which evaluates block doesn't matters because semantics is
local to process scope where given block is evaluated.

Trying to ensure "ensure" semantics even regardless of scheduling is
pointless and futile.
So, i am puzzled, what exactly "threading semantics" you trying to
preserve here.

--
Best regards,
Igor Stasenko.

Andreas.Raab

Re: [Pharo-project] BlockClosure>>ensure: implementation

Igor Stasenko wrote

Hmm.. your response puzzles me even more.

just simple example to show a controversy:

[ do something ] ensure: [ semaphore signal. anotherSemaphore wait ].

That isn't the point Eliot is making. The #valueNoContextSwitch affects the *receiver* of the ensure: message (not the argument) and only insofar as activating (entering) it is concerned; i.e., it prevents a process switch while entering the ensured block. I believe that originally we were trying to avoid any deviation from the interpreter's behavior and added this simply to ensure complete compatibility with the context VMs, but in hindsight I'm not certain this ever had any effect.

Cheers,
- Andreas