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 | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com