httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: A solution to the Win32 console problem
Date Sat, 17 Jun 2000 20:25:36 GMT
> From: TOKILEY@aol.com [mailto:TOKILEY@aol.com]
> Sent: Saturday, June 17, 2000 2:49 PM
> 
> In a message dated 00-06-16 15:50:10 EDT, William Rowe writes...
> 
> > > From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> >  > Sent: Wednesday, June 14, 2000 10:45 PM
> >  > 
> >  > RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL 
> >  > NICE TO WRAP THESE UP:
> >  > 
> >  >     * Add a simple Win32 hold console open patch (wait 
> for close or
> >  >         the ESC key, with a nice message) if the server died a 
> >  >         bad death (non-zero exit code) in console mode.
> >  >       OtherBill is working on this, but is open to any hints for
> >  >         forcing the unchecked 'Close Window on Exit' 
> opt's behavior.
> >  
> >  Ok... I have a -really friggin simple- solution to the 
> above problem.
> >  
> >  Change the invocation shortcut to
> >  
> >  %comspec% /k ApacheIcon.bat [whatever args here]
> >  
> >  Rem ApacheIcon.bat is provided for shortcut users to see 
> the results of
> >  Rem their commands without closing the console afterwards.
> >  Rem Setting a shortcut to execute the Apache.exe command 
> directly is
> >  Rem acceptable, but you will not see any errors once Apache closes.
> >  Rem You will need to review your error.log file to find 
> the problem.
> > 
> >  @@serverrootdrive@@:
> >  cd @@serverroot@@
> >  Apache %*
> >  Rem The Apache.exe program has terminated.  Type the exit 
> command or
> >  Rem click the window's close button to close this console window.
> >  
> >  Opinions?
> >  William Rowe
> 
> * KEEPING THE WIN32 CONSOLE ON EXIT...
> 
> The /K option might cause some problems with watchdog style scripts
> or batch files that are designed to re-start the server. If people
> don't add specific 'exit' commands to their scripts to close the
> console then you could end up with a box in the closet that
> re-generates so many 'kept' console windows that the available memory
> goes away and it will reach a point where the Server won't re-start
> anymore and will probably have to be re-booted to get rid of all
> the consoles.

If you use those, you should be using services, and the parent Apache
process is our watchdog (right?)  I agree... I've seen the horror,
but a warning in the batch file should be sufficient, nay?  These batch
files are -ONLY- for window shortcut users who don't know any better.

> In fear and trepidation I offer the following alternative...
> 
> ( NOTE: This does NOT provide a solution for GP Faults but
> then neither does /K. Even a Win32 console that was started
> with the /K 'keep' option will usually disappear in a puff
> of smoke if the problem is a GP fault. The suggestion is
> only for for tracking unexpected calls to 'exit()' ).

Agreed... earlier comments about SET probably should be evaluated
in terms of the 2.0 server, but not 1.3.x - and clean exit paths
in the 2.0 overhaul will make this whole task a breeze.

> Whenever I unpack a new copy of Apache source I simply add
> some macros to it that will 'catch' any calls to 'exit()'
> and let me read any console messages and/or choose to let
> the console go away. It does it on a TIMER if I am not there
> so that it still functions 'normally' and the console will
> be destroyed so watchdog scripts can get the right error
> code and safely 're-start' without resources disappearing.
> 
> As an example... the macro below is about as simple as it
> gets... but still retains the problem of 'holding up' the show
> and scripts or batch files designed to handle error recovery won't
> ever be able to kick in until someone presses a key...
> 
> #undef exit
> #define exit(code) \
>   printf("Press any key to perform exit(%d)...\n", code ); \
>   while(!kbhit()); \
>   exit(code);

It's simple, buck ugly, and I suggest you wrap it in a {} block...
or set this up as a little function.  But this -could- work.
 
> The next macro is 'the real deal'...
> 
> It accounts for multi-threading and uses a timer so that
> there is plenty of time to read the error message(s) but will
> still 'continue normally' if no one is around and the console
> still 'goes away'.
> 
> The best part about it is that it tells you EXACTLY where
> the 'exit()' is happening includng source file name and
> exact line number.
> 
> #ifdef WIN32
> 
> // EXIT CAPTURE MACRO
> 
> // Redefine the 'exit()' function so we can intercept all calls
> // and have the chance to read the error message(s) before the
> // console closes since it might not have been launched with
> // the /K 'keep' flag...
> 
> CRITICAL_SECTION g_exit_interceptor_critical_section1;
> long g_exit_interceptor_startup_time;
> long g_exit_interceptor_current_time;
> long g_exit_interceptor_elapsed_time;
> 
> // GetCurrentTime() works but Microsoft says it is now obsolete
> // and remains only for backward compatibility with 16 bit
> // programs. It would only break about a million 16 and 32 bit
> // programs if they dropped it but go ahead and use GetTickCount()
> // instead of GetCurrentTime() since it works just as well.
> //
> // MSVC and Borland will allow comments inside the macro but
> // both compilers have the same problem when it comes to
> // using the 'double-slash' single line comments. Both compilers
> // will screw up the macro unless it uses standard ANSI 'C' comment
> // style for each separate comment line with the 'line continuation'
> // marker at the end.
> 
> // Once this new 'exit()' macro has been defined and a thread
> // goes to issue an 'exit(99)' command ( or some other exit code )
> // this is what will appear on the console...
> 
> // ****> exit(99)
> // File: .\src\RCTPDW.C
> // Line: 197
> // Inside exit(99) critical section now...
> // The program will terminate in 30 seconds...
> // You may press any key during that time and
> // the wait loop will terminate early.
> //
> // Performing real exit(99) now...
> //
> // V:\RCI\SERVERS\RCTPDW >  <-- Actual exit to OS with error code 99
> 
> #undef exit
> #define exit(code) \
>   InitializeCriticalSection( 
> &g_exit_interceptor_critical_section1 ); \
>   EnterCriticalSection( &g_exit_interceptor_critical_section1 ); \
>   printf( "****> exit(%d)\n", code ); \
>   printf( "File: %s\n",  __FILE__ ); \
>   printf( "Line: %ld\n", (long) __LINE__ ); \
>   printf( "Inside exit(%d) critical section now...\n", code ); \
>   printf( "The program will terminate in 30 seconds...\n" ); \
>   printf( "You may press any key during that time and\n" ); \
>   printf( "the wait loop will terminate early.\n" ); \
>   g_exit_interceptor_startup_time = GetTickCount(); \
>   for ( ;; ) \
>      { \
>       if (kbhit()) break; \
>       g_exit_interceptor_current_time = GetTickCount(); \
>       g_exit_interceptor_elapsed_time = \
>       g_exit_interceptor_current_time - \
>       g_exit_interceptor_startup_time; \
>       /* Remember that all the times are in milliseconds so */ \
>       /* multiply the wait time in seconds by 1000... */ \
>       if ( g_exit_interceptor_elapsed_time > (30*1000) ) break; \
>      } \
>   printf( "\nPerforming real exit(%d) now...\n", code ); \
>   /* It isn't even necessary to release the critical section */ \
>   /* and, in fact, might be harmful to do so since other threads */ \
>   /* will get a few more CPU cycles when the critsec comes off. */ \
>   LeaveCriticalSection( &g_exit_interceptor_critical_section1 ); \
>   exit( code ); // Return original exit code to OS
> 
> #endif // WIN32

Ugh.  Again, a {} block is probably required.  And I'd really like
to see this delegated to a function.  We also have to watch how it
would interact with the new console_control_handler function...
and if a service (if the console_control_handler isn't registered)
only then run with it (that code could be a macro) but if you want 
to put this in the form of a 'functionalized' patch, I'd certainly 
consider it.  It's simply too dirty to be inlined for my tastes :-)
 
> * VIEWCVS
> 
> ( To William Rowe )...
> 
> Thanks for providing the VIEWCVS links!
> 
> I didn't even know there was such a thing. Pretty neat!

That's my job... and thank Greg for its current form :-)

> There is a way to receive all that HTML into your browser
> compressed upwards of 85 percent in real time. You don't
> need any sort of 'client' piece to do it... just any version
> of MSIE or Netscape or Opera that supports standard IETF
> Content-Encoding.
> 
> Proxy your browser to 12.17.228.52 port 5010
> and ask for the following Apache VIEWCVS document...
> 
> http://www.apache.org/websrc/viewcvs.cgi/apache-1.3/src/main/
> http_main.c.diff?r1=1.491&r2=1.503
> 
> The Online Internet Compression Server at 12.17.228.52:5010
> obtains the page from Apache at T3 speeds, compresses it
> dynamically upwards of 85 percent and then sends the highly
> reduced version back to your browser over the modem connection.
 
Fun... yes, I regularly zip up ebcdic print images of 100000+
pages, and yes, 95% compression is typical.
 
> Going through the Online Internet Compression Server
> at 12.17.228.52:5010 is the only thing that makes the
> VIEWCVS tolerable here in dial-up land.

No doubt, but next time I'll post a simplified diff link instead
for those who aren't so lucky.
 
> Before anyone 'jumps my ass' ( again ) on this forum for
> 'pushing a product' please realize the following...

I'll read it as a gift to Apache developers, amoung others.
Thank you for the link, and the ideas :-)

Bill

Mime
View raw message