From: Jeff Trawick <trawick@apache.org>
Date: Thu, 31 Oct 2002 09:30:43 +0000 (+0000)
Subject: add a comment lamenting the lack of a cleanup for the CGI child
X-Git-Tag: 2.0.44~183
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b143c6acc6ac8f96ef9e13ac7e050824df716e9e;p=thirdparty%2Fapache%2Fhttpd.git

add a comment lamenting the lack of a cleanup for the CGI child
process and mentioning some issues related to the problem


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97362 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/modules/generators/mod_cgid.c b/modules/generators/mod_cgid.c
index 5f0ffdba0bd..5efd48fcc5d 100644
--- a/modules/generators/mod_cgid.c
+++ b/modules/generators/mod_cgid.c
@@ -658,6 +658,21 @@ static int cgid_server(void *data)
                               apr_filename_of_pathname(r->filename));
             }
         }
+        /* SNAFU: no call to apr_pool_note_subprocess() to cause the
+         *        CGI to be cleaned up when the request ends (in case
+         *        client drops connection)...  can't write the pid back
+         *        to cgid_handler() because by the time we know the pid
+         *        the new CGI is already started and potentially writing
+         *        headers and body back to the handler...
+         *        perhaps cgid_handler() needs to provide a key with
+         *        a request to which cgid daemon will associate the
+         *        CGI pid...  at request_rec cleanup time, that key
+         *        gets sent back to cgid_handler() telling it to kill
+         *        whatever pid is associated with the key...
+         *        2 flows per request, which isn't cool...  but 
+         *        having the CGI running after client killed connection
+         *        isn't cool either...
+         */
     } 
     return -1; 
 }