Author ncoghlan
Recipients Mark.Shannon, deleted0524, erik.bray, gregory.p.smith, jdemeyer, ncoghlan, njs, xgdomingo, yselivanov
Date 2017-09-07.00:31:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1504744270.95.0.0346509148398.issue29988@psf.upfronthosting.co.za>
In-reply-to
Content
The updated PR fully resolves the synchronous CM case by switching to using threading.Lock as the test CM (as per Nathaniel's original suggestion). Without that, the pending exception was being processed as soon as __exit__() started running, so the test failed due to the lack of signal safety in the test CM itself.

For the asynchronous case, Greg and I aren't seeing any way to resolve the situation without somehow making the pending call processing event loop aware - otherwise even if the current frame postpones dealing with the pending call, it will still get processed as soon as YIELD_FROM returns control to the asyncio event loop. The one thing we think may work is to provide a way for asyncio (et al) to configure a thread such that all pending calls are routed to the thread's event loop for handling, rather than being processed directly by the eval loop.
History
Date User Action Args
2017-09-07 00:31:11ncoghlansetrecipients: + ncoghlan, gregory.p.smith, njs, Mark.Shannon, erik.bray, jdemeyer, yselivanov, deleted0524, xgdomingo
2017-09-07 00:31:10ncoghlansetmessageid: <1504744270.95.0.0346509148398.issue29988@psf.upfronthosting.co.za>
2017-09-07 00:31:10ncoghlanlinkissue29988 messages
2017-09-07 00:31:09ncoghlancreate