socket.recvfrom() & sendto()

[Donn Cave]

Quoth "Fredrik Lundh" <fredrik at pythonware.com>:
| Donn Cave wrote:
| > 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
|
| 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?

I assume "Unix specification" here is X/Open, and while Be doesn't
specifically claim to support that standard, I agree that would be
a reasonable expectation.  I bet I'm the first person to ever notice,
and I owe it all to asyncore.

|> 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.
|
| what second connect?  you only have to call it once; it'll return
| an EINPROGRESS error, and make the socket writable when it's
| done.

I dimly remembered that from Lynx, where, some time back, I had to
debug another obscure problem between select and non-blocking connect,
on AIX.  They do connect again, but now that I look at the source,
they expect an "is connected" error, and on UNIX I see that's what
happens.  So it isn't useful after all, unless you just want to
see connect errors actually come from the connect() function.

	Donn Cave, donn at u.washington.edu