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:
>> 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:
> > 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:
>> 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
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.
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
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
