Justin Cappos added the comment:
>> The Python implementation sets timeout=None (which implies that the
>> underlying socket is blocking).
>
>No, it doesn't. A socket may be non-blocking without having a timeout;
> that's the socket API (on all systems, not ju
Justin Cappos added the comment:
> > Well, I don't think setting a timeout on a listening socket and then
> > expecting the socket received through accept() to be non-blocking (but
> > only on BSD) is a legitimate application.
>
>
> Right. But setting the server
Justin Cappos added the comment:
>> 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 Pyt
Justin Cappos added the comment:
> Apparently, the designers of BSD thought differently. Remember that
> it is them who defined the socket API in the first place, so they
> have the right that their design decisions are considered.
I think there is a bit of confusion here. The &#
Justin Cappos added the comment:
Perhaps the right way to fix the problem without breaking code would be to
propose a new function for platform which would return a 'newbie readable'
string of the system type?
--
nosy: +Justin.Cappos
New submission from Justin Cappos :
Suppose there is a program that has a listening socket that calls accept to
obtain new sockets for client connections. socketmodule.c assumes that these
client sockets have timeouts / blocking in the default state for new sockets
(which on most systems
New submission from Justin Cappos <[EMAIL PROTECTED]>:
The behavior of popen vs popen[2-4] differs with respect to open file
descriptors (at least on the Linux implementation of popen). popen
does not close file descriptors, thus processes retain open file
descriptors from their parent.
