Proposal: Alias more powerful concurrency, and more powerful manipulation of try block

[DavidL]

在 Sat, 22 Sep 2007 13:56:26 +0800，Daniel Keep  
<daniel.keep.lists at gmail.com> 写道:

>
> I could be wrong, but I don't think any of this is even *remotely*  
> possible.
>
> What you're trying to do is access a piece of memory without having
> *any* idea where it is.  Consider your SEH example; there is simply no
> way for FilterFunc to know where func1.flag is.  Where that variable is
> stored depends entirely on what functions got called before it.  Hell,
> what if func1 has recursively called itself several times before calling
> FilterFunc?  What does the alias mean then?
>
The compiler has idea how the code is generated. So the specific code of  
accessing
func1.flag is *well* known at least in the implementation of the scope  
func1. Either
it's [EBP-0xC] or something else. It's fixed to the context no matter how  
the func1
recursively call itself several times. The FilterFunc tries to access to  
the local
vars of current context ( the func1 specific context ). Alias means the  
compiler en-
sure the accessing codegen is exactly the same as the func1. So under the  
same context
and with the memory not corrupted the func can access local vars which are  
restricted
to the scope of func1.

> What's more, look at how the code is structured; you call func1 from
> func, and then call into FilterFunc.  But by the time FilterFunc is
> called, func1's local state is no longer on the stack; it's more than
> likely been replaced by FilterFunc's own local state.
>

I don't think so, since there's EXCEPTION_CONTINUE_EXECUTION, at least  
win32 exception
won't destroy the stack frame when it tries to execute the FilterFunc.

> On a side note, I fail to see what this has to do with concurrency.
>

The idea is you can interact with concurrency code without placing  
specific code to handle
such staff.

> 	-- Daniel



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/