apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Tutt" <rassi...@lyra.org>
Subject RE: [PATCH] WIN32 Optimistic apr_proc_kill
Date Fri, 15 Feb 2002 23:57:08 GMT




> From: Mladen Turk [mailto:mturk@mappingsoft.com]
> 
> From: "Bill Tutt" <rassilon@lyra.org>
> 
> > This isn't a nicer way to kill child processes. While DLL cleanup
tasks
> > might happen you have no idea whether or not the app you're trying
to
> > terminate is in a state useful to try this out. The user still might
see
> > a Win32 generated A/V dialog (or worse) when you do try this trick.
> >
> We are calling kill, right?
> So If I launch APRized app (myself for example), then on exit the
child
> will
> call the apr_terminate that will call the clenup for all the sub-child
> processes too! Got It?

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. The child process
you're trying to kill might not be in safe state to have those functions
called. This may result in an access violation being generated and the
operating systems fall back structured exception handling routines will
kick in and display an A/V dialog. Displaying the dialog will cause your
process to hang and not actually accomplish anything useful than causing
your child process to hang.

I'm still not even sure what you want to have happen. APR when compiled
into a DLL doesn't appear to have a DllMain so calling ExitProcess() on
an APRized child process still won't kill it's child processes by
default. Terminate and ExitProcess definitely don't kill their child
processes by default. (Which really is beside the point, apr_proc_kill()
IMHO should be about killing arbitrary Win32 processes and not just
APRized processes.)

Bill


Mime
View raw message