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 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:16mcjeffsetrecipients: + mcjeff, gregory.p.smith, vstinner
2015-04-13 18:12:16mcjeffsetmessageid: <1428948736.53.0.150112821758.issue23863@psf.upfronthosting.co.za>
2015-04-13 18:12:16mcjefflinkissue23863 messages
2015-04-13 18:12:16mcjeffcreate