Author: rousskov

The connect(2) system call might return "connection ready"
status even for a non-blocking file descriptor. The connection
itself can never be immediately ready in reality because of the
TCP handshake, but I am guessing that in some environments, the
TCP stack fakes/optimizes local connection readiness. We have
seen that for loopback sockets on FreeBSD 6.2, for example, but
the behavior is probably OS- or OS-configuration specific.

If connect(2) is immediately successful, comm module
immediately calls the callback. This means that the callback is
called while the same callback is being registered with comm.
ICAP does not allow this "re-entrance" and other code might not
deal well with it.

The change overwrites connect(2) result so that Squid does not
think that connect(2) was immediately successful. Instead of
calling the callback, Squid then schedules the connection
write-ability check.

The NativeAsyncCall development will fix this and remove the
need to overwrite connect(2) result because comm will always
call callbacks asynchronously.

diff --git a/src/comm.cc b/src/comm.cc
index 5b9390a09d7c8f11b2560b5ed5b472f8f44e9c18..15cd0b75bcf56a1b340063980008d2391391c8eb 100644 (file)
--- a/src/comm.cc
+++ b/src/comm.cc
@@ -1,5 +1,5 @@
 /*
- * $Id: comm.cc,v 1.438.2.2 2008/02/25 23:08:50 amosjeffries Exp $
+ * $Id: comm.cc,v 1.438.2.3 2008/02/27 10:45:50 amosjeffries Exp $
  *
  * DEBUG: section 5     Socket Functions
  * AUTHOR: Harvest Derived
@@ -1253,6 +1253,13 @@ comm_connect_addr(int sock, const struct sockaddr_in *address)
 
         x = connect(sock, (struct sockaddr *) address, sizeof(*address));
 
+        // XXX: ICAP code refuses callbacks during a pending comm_ call
+        // Async calls development will fix this.
+        if (x == 0) {
+            x = -1;
+            errno = EINPROGRESS;
+        }
+
         if (x < 0)
             debugs(5, 9, "connect FD " << sock << ": " << xstrerror());
     } else