socket.recvfrom() & sendto()

[Donn Cave]

Quoth "Fredrik Lundh" <fredrik at pythonware.com>:
[... re BeOS gratuitous connect() "readable" causes asyncore recv ...]

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

Well, again, I can fix it by simply leaving the socket in its default
blocking state.  That's the only solution that asyncore could offer.
But otherwise, that is if you actually want an asynchronous connect(),
I call connect() a second time (!) from handle_connect(), which on BeOS
does not cause any error and clears the readable state.  Meanwhile
echo_client gets its own readable(), which calls asynchat.async_chat.readable()
if and only if already connected.

So in other words, I don't see how it could really be fixed in asyncore
either, and I wouldn't propose to try.  If BeOS is going to survive,
Be will have to release its long in beta testing, new from scratch
socket implementation along with the rest of the long awaited BeOS R6,
and these eccentricities will be history - by all accounts, it's much
more of a first class Berkeley style implementation.  If they don't,
they go off to live with the Amiga and other fossils.  Either way,
it's no more worth fixing for this than it would be for SVR4's quirks.

	Donn Cave, donn at u.washington.edu