Message297185
| Author | erik.bray |
|---|---|
| Recipients | Mark.Shannon, deleted0524, erik.bray, jdemeyer, ncoghlan, njs, yselivanov |
| Date | 2017-06-28.13:55:20 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1498658120.14.0.735648851701.issue29988@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
>> Or we could steal a bit in the opcode encoding or something. > That seems like a very reasonable and easy-to-implement solution. It > would generalize this check: https://github.com/python/cpython/blob/e82cf8675bacd7a03de508ed11865fc2701dcef5/Python/ceval.c#L1067-L1071 Interesting; I didn't notice that bit before. It seems like that does at least try to guarantee that a signal can't interrupt between: lock.acquire() try: ... which previously I assumed we couldn't make any guarantees about. But CPython at least does, or tries to. It would be good to generalize that. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2017-06-28 13:55:20 | erik.bray | set | recipients: + erik.bray, ncoghlan, njs, Mark.Shannon, jdemeyer, yselivanov, deleted0524 |
| 2017-06-28 13:55:20 | erik.bray | set | messageid: <1498658120.14.0.735648851701.issue29988@psf.upfronthosting.co.za> |
| 2017-06-28 13:55:20 | erik.bray | link | issue29988 messages |
| 2017-06-28 13:55:20 | erik.bray | create | |