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 570d762cbabb9299f4d6b74663aae3282ccfcd35..8e7789065b06dac7fcf7ab5ce8d32ebd728673c2 100644 (file)
--- a/src/comm.cc
+++ b/src/comm.cc
@@ -1,6 +1,6 @@
 
 /*
- * $Id: comm.cc,v 1.443 2008/02/08 01:56:33 hno Exp $
+ * $Id: comm.cc,v 1.444 2008/02/11 22:30:10 rousskov Exp $
  *
  * DEBUG: section 5     Socket Functions
  * AUTHOR: Harvest Derived
@@ -1330,6 +1330,13 @@ comm_connect_addr(int sock, const IPAddress &address)
 
         x = connect(sock, AI->ai_addr, AI->ai_addrlen);
 
+        // 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,5, "comm_connect_addr: sock=" << sock << ", addrinfo( " <<