socket.recvfrom() & sendto()

Fredrik Lundh fredrik at pythonware.com
Fri May 11 09:28:11 CEST 2001


Donn Cave wrote:
> | well, the Unix specification is clear on what an asynchronous
> | connect is supposed to do:
> |
> |     "When the connection has been established asynchronously,
> |     select() and poll() will indicate that the file descriptor for the
> |     socket is ready for writing.
> |
> | looks like a BeOS bug...
>
> I agree that it may be a bug, but does the above say that it can't
> also indicate the file descriptor is ready for reading?

only if there's data available to read -- which of course can happen
if the server starts sending stuff to you as soon as you connect, the
network is fast enough, and you get delayed on the way from the
connect to the select (asyncore handles that case).

it's not nice to say that the socket is readable, and then throw an
EWOULDBLOCK exception when you try to read from it.

not sure how to fix this in asyncore, really.  a simple-minded fix could
be to wrap the socket.recv call in dispatcher.recv in a try/except, and
let it return an empty string if it gets an EWOULDBLOCK error.  but that
only works well if the socket becomes writable reasonable soon, and if
BeOS doesn't always pretend it's readable even if there's no data...

Cheers /F





More information about the Python-list mailing list