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/608
there 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 <elcm at pacbell.net>
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 <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================