Message240692
| Author |
mcjeff |
| Recipients |
gregory.p.smith, mcjeff, vstinner |
| Date |
2015年04月13日.18:12:15 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1428948736.53.0.150112821758.issue23863@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Added a flag to allow for at least one run -- I know nothing of non-Linux clock resolution. That should handle that.
As for the thread safety of the socket timeouts, yeah, that was why I didn't do that initially, I assumed the suggestion to take that approach took the risk into account; you'll know far more about potential impact than I will.
Since this is at a higher abstraction than socket primitives, another option would be to track remaining time in thread local data so that we don't mutate the timeout on the object (which I don't really like doing anyway).
Thoughts on approach before I put it together? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2015年04月13日 18:12:16 | mcjeff | set | recipients:
+ mcjeff, gregory.p.smith, vstinner |
| 2015年04月13日 18:12:16 | mcjeff | set | messageid: <1428948736.53.0.150112821758.issue23863@psf.upfronthosting.co.za> |
| 2015年04月13日 18:12:16 | mcjeff | link | issue23863 messages |
| 2015年04月13日 18:12:16 | mcjeff | create |
|