Message184410
| Author |
Kevin.Barry |
| Recipients |
Kevin.Barry, emmanuel, vstinner |
| Date |
2013年03月18日.00:52:37 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1363567957.8.0.310483174698.issue14916@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
One additional issue, which my patch doesn't address, is that PyRun_InteractiveLoop should really take *two* FILE* arguments, with the second one being optional. This is because on Linux (and presumably on other *nixes) if a read operation is blocked on a file descriptor then write operations (from other threads) to the same file descriptor will also block. That doesn't happen in the current Python implementations because PyOS_Readline is always called with two FILE* objects, anyway (stdin and stdout.) I would, however, expect such a problem to appear if a user created a Python thread in the interactive session that periodically printed to the terminal, then read input from the terminal. In that case, I would expect to see no output from the thread while the read operations were blocked, but I haven't tested it. (I don't remember if this came up after I applied my patch locally.)
I actually considered this when I created the patch; however, I didn't feel like going to all the trouble of adding a member to tok and propagating the change throughout the entire core. I had hoped this bug would get more attention and I'd be able to discuss it with a developer involved in the Python project, but ultimately that didn't happen and I ended up forgetting about it.
Kevin Barry |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年03月18日 00:52:37 | Kevin.Barry | set | recipients:
+ Kevin.Barry, vstinner, emmanuel |
| 2013年03月18日 00:52:37 | Kevin.Barry | set | messageid: <1363567957.8.0.310483174698.issue14916@psf.upfronthosting.co.za> |
| 2013年03月18日 00:52:37 | Kevin.Barry | link | issue14916 messages |
| 2013年03月18日 00:52:37 | Kevin.Barry | create |
|