Author ncoghlan
Recipients Mark.Shannon, deleted0524, erik.bray, gregory.p.smith, jdemeyer, ncoghlan, njs, xgdomingo, yselivanov
Date 2017-09-04.18:09:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1504548598.39.0.657458334625.issue29988@psf.upfronthosting.co.za>
In-reply-to
Content
Greg Smith & I are looking at this at the core dev sprint, and we think some variant of the "atomic until" idea should work, but there's a prerequisite change to the way "async with" works: the "GET_AWAITABLE" opcodes need to be avoided in this case, as they call __await__, and hence may run arbitrary Python code.

We can't see any immediate barriers to moving those calls up into BEFORE_ASYNC_WITH, such that what ends up on the eval loop's stack is the already resolved iterable for use by YIELD FROM, rather than combining GET_AWAITABLE+YIELD_FROM the way a normal await expression does.

That would then give the preamble:

    BEFORE_ASYNC_WITH (resolves __aenter__ and __aexit__ to iterables)
    LOAD_CONST 0
    YIELD_FROM (need to skip signal processing here)
    SETUP_ASYNC_WITH

And the postamble:

    POP_BLOCK (need to skip signal processing until YIELD_FROM)
    LOAD_CONST 0
    WITH_CLEANUP_START
    LOAD_CONST 0
    YIELD_FROM
    WITH_CLEANUP_FINISH

We also agree that adding some kind of test injection hook (potentially limited to pydebug builds, depending on exactly how it works) is likely to be a necessary to be able to test this.
History
Date User Action Args
2017-09-04 18:09:58ncoghlansetrecipients: + ncoghlan, gregory.p.smith, njs, Mark.Shannon, erik.bray, jdemeyer, yselivanov, deleted0524, xgdomingo
2017-09-04 18:09:58ncoghlansetmessageid: <1504548598.39.0.657458334625.issue29988@psf.upfronthosting.co.za>
2017-09-04 18:09:58ncoghlanlinkissue29988 messages
2017-09-04 18:09:58ncoghlancreate