[Python-Dev] PEP 343 - next steps

[Nick Coghlan]

Nick Coghlan wrote:
> Nick Coghlan wrote:
> 
>>Then all the two new opcodes (e.g. ALLOW_ASYNC, BLOCK_ASYNC) would 
>>have to do is set the state of tstate->allow_async_exc appropriately.
> 
> 
> Actually, to allow the use of 'with' statements inside functions 
> called via EXPR and the call to __enter__, it would be necessary to 
> support nesting of calls to BLOCK_ASYNC and ALLOW_ASYNC, so a better 
> approach would be to make the field "tstate->block_async_exc", 
> incrementing it in BLOCK_ASYNC, and decrementing it in ALLOW_ASYNC.

And, replying to myself yet again. . .

Such an approach would obviously break in the face of an exception 
that occurs between the BLOCK_ASYNC and ALLOW_ASYNC opcodes (async 
exceptions would remain blocked in the thread).

This can be dealt with by storing the question of whether or not async 
exceptions are permitted as part of the *frame* state, rather than the 
thread state.

That is, make the field access be "f->allow_async_events", and have 
ALLOW_ASYNC and BLOCK_ASYNC set or clear that flag, respectively.

The error handling code after the main opcode switch statement can 
then simply set "f->allow_async_exc" back to true in order to ensure 
that handling of async exceptions is resumed correctly in the event of 
try/finally or try/except blocks causing further execution within the 
frame. (Given that only expressions are possible on the resource 
acquisition line, dealing with the WHY_EXPRESSION case seems to be all 
that would be needed).

Regards,
Nick.

P.S. My suggested semantics and the above implementation outline 
should be up on the Wiki shortly.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com