This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | pitrou |
|---|---|
| Recipients | anthonybaxter, christian.heimes, jafo, janixia, jhylton, loewis, pitrou, tim.peters |
| Date | 2008年03月28日.22:45:06 |
| SpamBayes Score | 0.0021040312 |
| Marked as misclassified | No |
| Message-id | <1206744308.79.0.450831305038.issue815646@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Why hadn't I read #595601 in detail, it has an explanation: [quoting Jeremy Hylton] The universal newline code is squirrels the FILE * in a local variable, which is worse. If it happens that another thread closes the file, at best the local points to a closed FILE *. But that memory could get recycled and then there's no way to know what it points to. [/quoting] Even with careful coding, there's a small window between releasing the GIL on our side, and acquiring the FILE-specific lock in the glibc, during which the fclose() function can be invoked and release the FILE just before we invoke another function (e.g. fseek()) on it. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年03月28日 22:45:09 | pitrou | set | spambayes_score: 0.00210403 -> 0.0021040312 recipients: + pitrou, tim.peters, loewis, jhylton, anthonybaxter, jafo, janixia, christian.heimes |
| 2008年03月28日 22:45:08 | pitrou | set | spambayes_score: 0.00210403 -> 0.00210403 messageid: <1206744308.79.0.450831305038.issue815646@psf.upfronthosting.co.za> |
| 2008年03月28日 22:45:07 | pitrou | link | issue815646 messages |
| 2008年03月28日 22:45:06 | pitrou | create | |