----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>

> Hmm.. i think, you given a bad example. It depends on 'knowledge' that
> #ifTrue: is optimized by compiler as an execution branch, but not a
> regular message send.

My example was specifically what to do when we have ifTrue: optimized.  But 
you are right to consider the general case first.

> For general case we should consider passing a block as a argument, like:
>
> bar someMethod: [^1].
>
> But this again, not includes cases, when blocks are assigned to
> temps/ivars within context and never passed as arguments to
> message(s).

But we do know that these blocks are actually created in the home context 
(unlike the optimizing example I gave-no blocks are created).  So if it were 
possible to mark the block context, that it includes an explicit return, 
then those are the blocks that should cause synchronization with promises. 
We could know that a block has a return at compile time, so we would just 
need to have a new block creation bytecode that marked the block: 
#bytecodePrimBlockCopyWithReturn.

>
> I thought a bit about marking a method context containing blocks with
> non-local returns with special flag, which will force context to not
> activate until all free variables in method are resolved
> (agruments/temps). This means that before any activation (entering
> method and each send in method it will wait for resolving all promises
> it contains).
> But i'm still doubt if this gives us anything.

Where does a block return from if it has an explicit return?  The home 
context or the calling context?   I think it is the calling context.

So what you just said about marking a method context if it contains blocks 
with non-local returns.  How do you know the block has a non-local return? 
As I mentioned, we could mark the blocks.   We could mark the methods that 
CREATE blocks that return.  At runtime, we could look at the method flag for 
non-local return and look at all args and temps for blocks with the flag and 
synchronize.  I agree with you that it will have to be before every send.

>
> There is many methods which operate with blocks by sending #value.. to
> them. And these methods actually don't care if those blocks contain
> non-local returns or not. They simply do their job.

What do you mean here?


Cheers,
Rob