Message164150
| Author |
tim.golden |
| Recipients |
Devin Jeanpierre, Dude-X, amaury.forgeotdarc, brian.curtin, christian.heimes, loewis, mhammond, pitrou, r.david.murray, ronaldoussoren, santoso.wijaya, tim.golden |
| Date |
2012年06月27日.13:04:05 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1340802246.22.0.447176582953.issue1677@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
OK, I've run out of time to look, but the culprit looks like it's an odd interaction between my_fgets in myreadline.c and the interrupt handler in signal. There's a section of code which is conditional on ERROR_OPERATION_ABORTED being returned from fgets in the CRT.
That then tries to play ball with a the interrupt handler having fired already (in a separate thread) by sleeping for one second and checking that the handler was tripped. If it has then the function returns one and stuff happens elsewhere; it it hasn't then the function behaves as if EOF (ie Ctrl-Z) was pressed and Python exits.
That's as far as I've got; it looks like a race condition of some sort but I can't see where. I'm not 100% sure that the SIGINT handler is tripping. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年06月27日 13:04:06 | tim.golden | set | recipients:
+ tim.golden, loewis, mhammond, ronaldoussoren, amaury.forgeotdarc, pitrou, christian.heimes, Dude-X, Devin Jeanpierre, r.david.murray, brian.curtin, santoso.wijaya |
| 2012年06月27日 13:04:06 | tim.golden | set | messageid: <1340802246.22.0.447176582953.issue1677@psf.upfronthosting.co.za> |
| 2012年06月27日 13:04:05 | tim.golden | link | issue1677 messages |
| 2012年06月27日 13:04:05 | tim.golden | create |
|