1 files changed, 52 insertions, 3 deletions

diff --git a/unix/tclUnixChan.c b/unix/tclUnixChan.c
index 93bb1fe..fc3c10f 100644
--- a/unix/tclUnixChan.c
+++ b/unix/tclUnixChan.c
@@ -150,6 +150,7 @@ typedef struct TcpState {
     int fd;			/* The socket itself. */
     int flags;			/* ORed combination of the bitfields defined
 				 * below. */
+    int interest;		/* Events types of interest. */
     Tcl_TcpAcceptProc *acceptProc;
 				/* Proc to call on accept. */
     ClientData acceptProcData;	/* The data for the accept proc. */
@@ -2198,6 +2199,30 @@ TcpGetOptionProc(
  */
 
 static void
+WrapNotify(
+    ClientData clientData,
+    int mask)
+{
+    TcpState *statePtr = (TcpState *) clientData;
+    int newmask = mask & statePtr->interest;
+
+    if (newmask == 0) {
+	/*
+	 * There was no overlap between the states the channel is
+	 * interested in notifications for, and the states that are
+	 * reported present on the file descriptor by select().  The
+	 * only way that can happen is when the channel is interested
+	 * in a writable condition, and only a readable state is reported
+	 * present (see TcpWatchProc() below).  In that case, signal back
+	 * to the caller the writable state, which is really an error
+	 * condition.
+	 */
+	newmask = TCL_WRITABLE;
+    }
+    Tcl_NotifyChannel(statePtr->channel, newmask);
+}
+
+static void
 TcpWatchProc(
     ClientData instanceData,	/* The socket state. */
     int mask)			/* Events of interest; an OR-ed combination of
@@ -2214,9 +2239,30 @@ TcpWatchProc(
 
     if (!statePtr->acceptProc) {
 	if (mask) {
-	    Tcl_CreateFileHandler(statePtr->fd, mask,
-		    (Tcl_FileProc *) Tcl_NotifyChannel,
-		    (ClientData) statePtr->channel);
+
+	    /*
+	     * Whether it is a bug or feature or otherwise, it is a fact
+	     * of life that on at least some Linux kernels select() fails
+	     * to report that a socket file descriptor is writable when
+	     * the other end of the socket is closed.  This is in contrast
+	     * to the guarantees Tcl makes that its channels become
+	     * writable and fire writable events on an error conditon.
+	     * This has caused a leak of file descriptors in a state of
+	     * background flushing.  See Tcl ticket 1758a0b603. 
+	     *
+	     * As a workaround, when our caller indicates an interest in
+	     * writable notifications, we must tell the notifier built
+	     * around select() that we are interested in the readable state
+	     * of the file descriptor as well, as that is the only reliable
+	     * means to get notified of error conditions.  Then it is the
+	     * task of WrapNotify() above to untangle the meaning of these
+	     * channel states and report the chan events as best it can.
+	     * We save a copy of the mask passed in to assist with that.
+	     */
+		
+	    statePtr->interest = mask;
+	    Tcl_CreateFileHandler(statePtr->fd, mask|TCL_READABLE,
+		    (Tcl_FileProc *) WrapNotify, (ClientData) statePtr);
 	} else {
 	    Tcl_DeleteFileHandler(statePtr->fd);
 	}
@@ -2404,6 +2450,7 @@ CreateSocket(
     if (asyncConnect) {
 	statePtr->flags = TCP_ASYNC_CONNECT;
     }
+    statePtr->interest = 0;
     statePtr->fd = sock;
 
     return statePtr;
@@ -2675,6 +2722,7 @@ MakeTcpClientChannelMode(
     statePtr = (TcpState *) ckalloc((unsigned) sizeof(TcpState));
     statePtr->fd = PTR2INT(sock);
     statePtr->flags = 0;
+    statePtr->interest = 0;
     statePtr->acceptProc = NULL;
     statePtr->acceptProcData = NULL;
 
@@ -2792,6 +2840,7 @@ TcpAccept(
     newSockState = (TcpState *) ckalloc((unsigned) sizeof(TcpState));
 
     newSockState->flags = 0;
+    newSockState->interest = 0;
     newSockState->fd = newsock;
     newSockState->acceptProc = NULL;
     newSockState->acceptProcData = NULL;