apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [PATCH] WIN32 Optimistic apr_proc_kill
Date Sat, 16 Feb 2002 17:47:29 GMT
From: "Mladen Turk" <mturk@mappingsoft.com>
Sent: Saturday, February 16, 2002 7:09 AM
> 
> From: "Bill Tutt" <rassilon@lyra.org>
> Sent: Saturday, February 16, 2002 12:57 AM
> 
> > Not quite. Yes we're calling kill, but you also don't want an A/V dialog
> > to pop up and prevent the process from exiting.  The reason that this is
> > possible is because ExitProcess causes DLL entry points to get called
> > with a notification that the process is exiting.

> So if instead WaitForSingleObject(proc->hproc, INFINITE);

> My primary concern was to kill the child that created the childs of its own.
> This is the major problem IMO with the apr_proc_kill, because the CGI child
> for example will hang causing processor overload.
> 
> My primary intention was to kill the entire process tree. (I'll try to do
> that using PSAPI and VDMDBG).

How do you _KNOW_ that the process created _should_ be killed, even if you walk
the tree with the NtApi functions?  E.g. imagine spawning a common app for 
managing Apache, e.g. ApacheMonitor, within the process.  It's Parent is your
app, but that process answers to all processes outside of that process chain,
as well.  I'm strongly -1 on this solution.

Let's see how we 'aught' to let a process close itself;

1. Slam closed the stdin handle - "nothing interesting here folks, move on"
   will cause a good number of apps to terminate.

2. Slam closed the stdout handle - "sorry, we aren't listening, move on!"

3. If the app is console - inject the Ctrl+Break (louder than Ctrl+C)
   [may need to occur before 1. above]

4. If the app has a main window, send it WM_EXIT.

5. -perhaps- inject the ExitProcess into the app.

The problems with 5. are as Bill noted; and the fact that most apps were never
coded to anticipate this action.  It's probably _more_ dangerous than killing the
process outright.

FirstBill's solution sounded more on the mark ... share state information between
the child and parent process.  When the child dies, the parent mops up all the
child's -registered- other children.  This solves my first question above.  And the
processes of those processes?  If they are coded correctly to react to one of the
four occurances above, they have a chance to mop up.  Because the parent of the
now-defunct child process is doing mop-up, it can give more time for these to happen
cleanly before wonking the other children [10 seconds total, perhaps.]

Even the clib isn't implemented, IIRC, in terms that Mladen has proposed here,
it's cleanups are in _endthread()/exit().  But here's a big consideration... if the
process won't clean itself up in reaction to common end-of-app signals, it's faster
(less CPU intensive) for the kernel to simply mop up than asking it to terminate 
a process, I expect.

The upshot?  This requires some well thought out action before we begin injecting
code into other processes.  But I agree with the concensus here, we need to support
both apr and non-apr app execution, clean up both, and it would be terrific to be
able to drop the 16 bit apps.  Perhaps as a build-time option, and create a new
symbol APR_HAS_LEGACY_CREATE_CHILD or something for those that -need- this.  Keep
in mind that pretty soon, the 32 bit apps will be legacy within the 32-bit WOW in
64-bit Windows :)

Bill



Mime
View raw message