VM crashes was: The State of Exceptions
Michael S. Klein
mklein at alumni.caltech.edu
Tue Oct 20 04:21:22 UTC 1998
> The special case when
> this should make a difference is when a block context is created within a
> method and stored in a live object. Nilling out the sender reference in
> this case prevents the whole sender chain from being kept alive. (Mike,
> this might be the answer to your earlier question).
>
> --Vassili
Unfortunately the semantics of the above statement differ between Squeak
& VW since, in Squeak, the block context is created before the block is
evaluated, and in VW, when it is evaluated. Both systems, of course, set
the sender at evaluation time. Since this is Squeak-list, I'll run with
that. Besides, capturing the right block context in VW is trickier than
bc := [ ... ].
When the block context is created, their is no sender.
So, I was about to make the statement:
"All of this talk about continuations is fine and dandy,
but shouldn't we work on getting true closures first?"
But, rather, I thought I'd probe Squeak to see how it handled certain
situations... So I wrote the following method (Answer is global):
(In Integer, as if it mattered):
foo
| bc sem |
Answer := #noValue.
bc := [^3].
sem := Semaphore new.
[Answer := bc value. sem signal] fork.
sem wait.
^bc
I evaluated '3 foo'
Now I was expecting Answer to be unchanged (from #noValue),
and the new process to continue along the original process's sender chain,
leaving the original process waiting forever on an unsignaled semaphore.
But, instead, it crashed the VM. Oh well....
ANSI X3J20 rev1.9 3.4.5.1 Paragraph 2
says it is undefined.
-- Mike
'Class new new' fares little better...
More information about the Squeak-dev
mailing list
|