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 Justin.Cappos
Recipients Justin.Cappos, bbangert, exarkun, giampaolo.rodola, loewis, ned.deily, nicdumz, pitrou, ronaldoussoren, roysmith
Date 2010-11-21.20:26:55
SpamBayes Score 7.286251e-10
Marked as misclassified No
Message-id <1290371216.68.0.900140278132.issue7995@psf.upfronthosting.co.za>
In-reply-to
Content
>> This implementation assumes that the OS sets any socket it receives
>> via accept to nonblocking.   (this is a false assumption on BSD)
>
> Not true. It doesn't assume that (it doesn't assume the reverse,
> either).

The Python implementation sets timeout=None (which implies that the
underlying socket is blocking).


>> The end result is that the OS has a nonblocking socket and the Python
>> object thinks it is blocking.   This is why the socket object in
>> Python has timeout=None yet calling fcntl shows the socket is
>> nonblocking.
>
> That conclusion is flawed. Python has not associated a timeout with
> the socket. It makes no claims as to whether the socket is blocking
> or not. So you have created a non-blocking socket without timeout.

The problem is that it has.   It has created a new Python socket
object with a specific value for timeout (None), but the underlying
socket is nonblocking.

The docs state that timeout = None makes the socket blocking.
History
Date User Action Args
2010-11-21 20:26:56Justin.Cappossetrecipients: + Justin.Cappos, loewis, ronaldoussoren, exarkun, roysmith, pitrou, giampaolo.rodola, ned.deily, nicdumz, bbangert
2010-11-21 20:26:56Justin.Cappossetmessageid: <1290371216.68.0.900140278132.issue7995@psf.upfronthosting.co.za>
2010-11-21 20:26:55Justin.Capposlinkissue7995 messages
2010-11-21 20:26:55Justin.Capposcreate