On 24 October 2012 00:57, Eliot Miranda <eliot.mira...@gmail.com> wrote: > > > > On Mon, Oct 22, 2012 at 2:17 AM, Clément Bera <clement.b...@inria.fr> 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.
