Windows cgi problem
This might also be a problem on unix but I haven't tested.
When cgi's are launched a window sometimes pops up, same for
mod_include exec cgi. Is there a reason we are not
launching the cgi as a detached process?
Index: mod_cgi.c
===
RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgi.c,v
retrieving revision 1.113
diff -u -d -b -r1.113 mod_cgi.c
--- mod_cgi.c 2001/12/13 17:22:20 1.113
+++ mod_cgi.c 2001/12/13 18:49:03
@@ -446,6 +446,7 @@
couldn't set child process attributes: %s, r-filename);
}
else {
+apr_procattr_detach_set(procattr, 1);
procnew = apr_pcalloc(p, sizeof(*procnew));
if (e_info-prog_type == RUN_AS_SSI) {
SPLIT_AND_PASS_PRETAG_BUCKETS(*(e_info-bb), e_info-ctx, e_info-next,
rc);
Allan
Re: Windows cgi problem
On Thursday 13 December 2001 11:02 am, Allan Edwards wrote: This might also be a problem on unix but I haven't tested. When cgi's are launched a window sometimes pops up, same for mod_include exec cgi. Is there a reason we are not launching the cgi as a detached process? You definately do not want to detach on Unix, because if you do, the CGI script will end up forking three times. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Windows cgi problem
From: Allan Edwards [EMAIL PROTECTED] Sent: Thursday, December 13, 2001 1:02 PM This might also be a problem on unix but I haven't tested. When cgi's are launched a window sometimes pops up, same for mod_include exec cgi. Is there a reason we are not launching the cgi as a detached process? Yes. They are broken for all 16 bit CGIs. We need some mechansim to pass off the fact that we've tested, and it is a good, well behaved 32 bit app. Because 16bitters invoke their own console thunk, they fail to ever clean up pipes correctly, hanging the connections. Bill
Re: Windows cgi problem
Ryan Bloom [EMAIL PROTECTED] writes: On Thursday 13 December 2001 11:02 am, Allan Edwards wrote: This might also be a problem on unix but I haven't tested. When cgi's are launched a window sometimes pops up, same for mod_include exec cgi. Is there a reason we are not launching the cgi as a detached process? You definately do not want to detach on Unix, because if you do, the CGI script will end up forking three times. yep... beyond that is the issue that detached on Win32 and detached on Unix really mean different things... what if we had a long-running-daemon attribute and a non-interactive attribute (yeah, please come up with better names): long-running-daemonnon-interactive Win32child doesn't get window child doesn't get window Unix all the forks, setsid, whatever no-op (just a rough sketch, but you get the picture) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Windows cgi problem
From: Ryan Bloom [EMAIL PROTECTED] Sent: Thursday, December 13, 2001 1:09 PM On Thursday 13 December 2001 11:02 am, Allan Edwards wrote: This might also be a problem on unix but I haven't tested. When cgi's are launched a window sometimes pops up, same for mod_include exec cgi. Is there a reason we are not launching the cgi as a detached process? You definately do not want to detach on Unix, because if you do, the CGI script will end up forking three times. Actually, something smells wrong here. It sounds like we are possibly detaching, and thus activating a console. We should have a console, it should be hidden, and we should behave ourselves (exactly as unix does.) Bill
Re: Windows cgi problem
From: Jeff Trawick [EMAIL PROTECTED] Sent: Thursday, December 13, 2001 1:17 PM what if we had a long-running-daemon attribute and a non-interactive attribute (yeah, please come up with better names): long-running-daemonnon-interactive Win32child doesn't get window child doesn't get window Unix all the forks, setsid, whatever no-op Child must have window, or pipes are broken on Windows. The difference is that we need to create the worker child window detached, and hidden. The CGI and other execs within the child should occur attached in it's own (hidden) window, and the parent window remains quiet amidst the storm :) Guess we aren't doing that right now, I'll try to jump on it. Bill
