Well as I become one of these older grey bearded smalltalkers I feel
obligated to reply.
The squeak-developer list (note the developer) started over 10++ years
back, in checking out of curiosity the oldest, well second oldest
email in my mail system
is Hmmm.... a rather deep discussion between Eliot, Dan and Ian about
"Implementing unwind-protect without virtual machine modification"
Certainly any discussion of deep internals is in the original spirit
of the list. I'll remind folks that via
http://wiki.squeak.org/squeak/608there are quite a number of more novice lists and special interest
ones. There is the developer list, but in general that sees less
traffic and
I think there is general interest in the Hydra VM since lots of people
are running around now with dual cpu machines wanting to exploit their
performance.
Date: Thu, 07 Aug 1997 09:32:39 -0700
From: Eliot & Linda <
[hidden email]>
Subject: Implementing unwind-protect without virtual machine
modification
> Hmmm....
>
> I had also been of the opinion that one needed VM modifications to
> catch unwind-protects. But I think I'm right in thinking one could
> use
> the existing cannotReturn mechanism, not that this is efficient or
> without its own complications. Here's a sketch:
>
> I'll use the VSE/ANSI syntax (its less verbose and more abstact).
>
>
> In the no-VM-modifications scheme ifCurtailed: (valueOnUnwindDo:) and
> ensure: (valueNowOrOnUnwindDo:) must prevent ^-returns from happening,
> and interpret them later. e.g.
>
> BlockClosure methods for unwind protection
> ifCurtailed: aBlock
> | savedSender result |
> savedSender := self home sender.
> "Set my sender's sender to nil so that any attempt to return
> from self
> self home setSender: nil.
> result := self value.
> self home setSender: savedSender.
> ^result
>
>
> Now...
>
> The cannotReturn method needs to search for all ifCurtailed: and
> ensure:
> contexts along the chain, following the stack through savedCaller,
> presumably by assuming that savedCaller is accessible as a temporary
> with a known index (i.e. in the above aContext tempAt: 2).
>
> The same indirect stack tracing (through savedSender) must be used
> when
> searching for exception handlers.
>
>
> So Dan's context design looks like its more than sufficient. However,
> the above implementation would probably cause havoc in an
> implementation
> that mapped contexts to real stack frames, and is unlikely to be
> efficient.
> _______________,,,^..^,,,_______________
> Eliot
On Feb 24, 2008, at 6:49 PM, Igor Stasenko wrote:
> Hello there,
>
> To all users of this list:
> - do you think that this list is wrong place for discussions around
> HydraVM?
> - if so, where you think it would be better, at vm-dev list, or at
> separate list?
>
> Currently i'm very active in this area and understand, that not all
> people in this list, interesting in it. So, maybe it's time to move
> to another place?
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
--
=
=
=
========================================================================
John M. McIntosh <
[hidden email]>
Corporate Smalltalk Consulting Ltd.
http://www.smalltalkconsulting.com=
=
=
========================================================================
Locked
