Issues with select
Issues with select
- Subject: Issues with select
- From: Aaron Ballman <email@hidden>
- Date: Thu, 29 Apr 2004 16:25:36 -0500
I'm going to preface this with: I know this is going to be a
forehead-smacking problem.... ;-)
The issue is, when I call connect on the loopback and a port that
doesn't exist, for some reason the bit set for WRITE is being flagged
instead of an error. The socket is in non-blocking mode, and here's
(what I think) the relevant code:
.
.
.
// Define our select sets and zero them out
fd_set read, write, errors;
FD_ZERO( &read );
FD_ZERO( &write );
FD_ZERO( &errors );
if (CanRead()) {
FD_SET( mSocket, &read );
}
if (CanWrite()) {
FD_SET( mSocket, &write );
}
FD_SET( mSocket, &errors );
// Do the select with no timeout
static struct timeval timeout = { 0, 0 }; // return immediately
long result = v_select( mSocket + 1, &read, &write, &errors,
&timeout );
if (0 == result) {
// The timeout expired, or there are no
// pending operations to do. This is
// no big deal
} else if (result > 0) {
// We selected something, so we should handle it
// appropriatly. Also make sure we still have a valid
// file descriptor, otherwise that causes the FD_*
// functions to crash.
if (-1 != mSocket and FD_ISSET( mSocket, &read )) {
// read-type operations
if (mAccepting) {
// Since we're in the accepting state, we
// should complete the accept here.
DoAccept();
} else if (!mIsConnected) {
// We're now connected! Let the user know!
mIsConnected = true;
// Be sure to flag the fact that we
just connected
// so that we can fire the event when
appropriate
mJustConnected = true;
} else {
// We're already connected, and so we should
// just start grabbing the data
if (not RecvToBuffer()) return;
}
}
// Check for an invalid socket descriptor at this point
// since DoAccept or RecvToBuffer may have closed the socket
// down.
if (-1 != mSocket and FD_ISSET( mSocket, &write )) {
// write-type operations
if (!mIsConnected) {
// We weren't connected yet, so let's say
// we're connected
mIsConnected = true;
// Be sure to flag that we just
connected so that we
// can let the user know
mJustConnected = true;
} else {
// Writing is no longer blocked since we
// got this message from select
mWrite_blocked = false;
// Try to send some more data out
// from our buffer
SendFromBuffer();
}
}
if (-1 != mSocket and FD_ISSET( mSocket, &errors )) {
if (not mIsConnected) {
// If we're not connected, then this
is (most likely)
// a problem with resolving the DNS adress.
SocketError( netDNRErr );
} else {
// Otherwise, we're not connected anymore.
SocketError( netLostConnectionErr );
}
}
} else {
// We got an error, so we should query errno and
// respond
SocketError( v_errno );
}
.
.
.
Sorry for the monster code snippet... :-/ In any event. When I call
connect on 127.0.0.1:9009, I get into this method (it's a Poll
method), and FD_ISSET( mSocket, &write ) claims that we have a
writing operation to do. I interpret this to mean that we're
connected. I was going off the understanding that an error would be
flagged in "errors", not in "write" or "read". Consequently, if I
try the same stunt with www.google.com:9009, everything works as
expected (the errors flag gets set, the write flag does not).
So, am I just misunderstanding something here, or is this a bug that
I stumbled across? I'm using OS 10.3.3...and FWIW, I'm betting it's
my problem, not the OSes. :-P
Any suggestions/enlightening statements?
~Aaron
--
In response to a stupid question I once asked: "My brain uses
patterns to format responses to your inputs, but I don't have one for
that. Do you speak German?" ~ Zola
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.