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 neologix
Recipients georg.brandl, gvanrossum, neologix, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2014-01-25.16:04:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM23Sh+r_Lrz7kzsC4XrE=syz6DHuBDRPE_jcYaFJ2LnoA@mail.gmail.com>
In-reply-to <1390557889.63.0.375947112319.issue20311@psf.upfronthosting.co.za>
Content
> If the patch is accepted, my changes on Python 3.3 should also be
reverted.

I'm sorry, but I'm not convinced.
The selector's granularity is an implementation detail, and I don't think
it should be exposed.
Furthermore, it's not a mere function of the C type used to represent the
timeout to the underlying syscall (long, timeval): it also depends on the
operating system, the hardware, etc.

Once again, what's wrong with your initial approach of ceiling the timeout?
It does seem reasonable to round away from zero, to ensure - not taking OS
bugs/limitations - that select() will wait at least the passed timeout.
History
Date User Action Args
2014-01-25 16:04:04neologixsetrecipients: + neologix, gvanrossum, georg.brandl, pitrou, vstinner, python-dev, serhiy.storchaka
2014-01-25 16:04:04neologixlinkissue20311 messages
2014-01-25 16:04:03neologixcreate