socket.recvfrom() & sendto()

[Donn Cave]

Quoth "Fredrik Lundh" <fredrik at pythonware.com>:
| Donn Cave wrote:
|> But from what I can tell, whether asyncore sockets are blocking
|> or non-blocking makes no difference.  It does use select to
|> dispatch, and select does block.  I have no idea why asyncore
|> sets its sockets to nonblocking.
|
| how do you do a non-blocking connect with a blocking
| socket?

Don't, obviously.  But that's just where it bites me!  I don't
actually use asyncore, though it looks like a good thing generally,
but I needed to look at it because the asynchat unit test fails on
BeOS.  On that platform's currently somewhat less than industrial
strength socket implementation, the "non-blocking connect has completed"
state makes the socket "readable" from select's point of view.
That may well be bug, I don't know.  At worst, it's a pretty obscure
matter!  Anyway, it breaks the test because asyncore goes to recv(),
which raises EWOULDBLOCK.

I haven't had a chance to run test_asynchat on a UNIX platform, but it
looks to me like the client doesn't handle the non-blocking connect
properly anyway - I don't see where it does the second connect.

But the asynchat test would work fine with a blocking socket.  It's
great that asyncore supports non-blocking operations, including connect -
that can be very useful.  It could even be useful on BeOS, as long
as you know to compensate for that quirk.  But asyncore works fine
with sockets in their default blocking state, and it would be more
robust if it left them that way, by default.

	Donn Cave, donn at u.washington.edu