apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject Re: [PATCH] WIN32 Optimistic apr_proc_kill
Date Sat, 16 Feb 2002 13:09:33 GMT

----- Original Message -----
From: "Bill Tutt" <rassilon@lyra.org>
To: "'Mladen Turk'" <mturk@mappingsoft.com>; "Bill Tutt"
<rassilon@lyra.org>; <dev@apr.apache.org>
Sent: Saturday, February 16, 2002 12:57 AM
Subject: RE: [PATCH] WIN32 Optimistic apr_proc_kill

> 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.

You are right about that situation. If there is inside some chils's dll
something like:

                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved)
    switch (ul_reason_for_call)
                MessageBox(NULL, "Are You Sure?", "DUMMY",
                            MB_OK | MB_ICONERROR);
    return TRUE;

my patch will hang.
So if instead WaitForSingleObject(proc->hproc, INFINITE);
I propose to use something like:

                if (WaitForSingleObject(proc->hproc, 100) == WAIT_TIMEOUT)
                    TerminateProcess(proc->hproc, exit_code);

That will kill the process for sure, but wouldn't prevent the A/V dialog :)
The dialog keeps hanging even after I explicily terminate the process.
Didn't test those cases.

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).

> 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.)

DllMain comes from CRT.

Thanks for your replies couse you make me figure out what I've missed from
the entire concept:

1. We need to track all the resources that are called from the APR and call
its cleanup.
2.  I found that there are number of them that doesn't comply with that
general APR concept. apr_proc lacks the cleanup for example.
3 . apr_terminate MUST free all the apr allocated resources.


View raw message