Message 301278 - Python tracker

Message301278

Author	ncoghlan
Recipients	Mark.Shannon, deleted0524, erik.bray, gregory.p.smith, jdemeyer, ncoghlan, njs, xgdomingo, yselivanov
Date	2017-09-04.22:48:10
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1504565290.89.0.293379113678.issue29988@psf.upfronthosting.co.za>
In-reply-to

Content
Right, if you look at the comments in the draft test case, we realised there are three things we currently need to protect: 1. POP_BLOCK -> WITH_CLEANUP_START (synchronous CM) 2. POP_BLOCK -> GET_AWAITABLE (asynchronous CM) 3. GET_AWAITABLE -> YIELD_FROM (asynchronous CM) Now that I have a test case, I'm going to start looking at defining a new DEFER_PENDING_UNTIL opcode that skips pending call processing (and hence signals) until that particular opcode offset is reached.

Content

Right, if you look at the comments in the draft test case, we realised there are three things we currently need to protect:

1. POP_BLOCK -> WITH_CLEANUP_START (synchronous CM)
2. POP_BLOCK -> GET_AWAITABLE (asynchronous CM)
3. GET_AWAITABLE -> YIELD_FROM (asynchronous CM)

Now that I have a test case, I'm going to start looking at defining a new DEFER_PENDING_UNTIL opcode that skips pending call processing (and hence signals) until that particular opcode offset is reached.

History
Date	User	Action	Args
2017-09-04 22:48:10	ncoghlan	set	recipients: + ncoghlan, gregory.p.smith, njs, Mark.Shannon, erik.bray, jdemeyer, yselivanov, deleted0524, xgdomingo
2017-09-04 22:48:10	ncoghlan	set	messageid: <1504565290.89.0.293379113678.issue29988@psf.upfronthosting.co.za>
2017-09-04 22:48:10	ncoghlan	link	issue29988 messages
2017-09-04 22:48:10	ncoghlan	create