Propblem with TerminateProcess
in [Win32 Kernel]
|
From: Emil Dotchevski on 9 Feb 2010 13:56 On Feb 8, 7:55 am, "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardba...(a)community.nospam> wrote: > > "Emil Dotchevski" <emildotchev...(a)gmail.com> wrote in message > >news:823dbb82-a5e1-40ca-8d9e-fcea24415598(a)m27g2000prl.googlegroups.com.... > > Hector, thanks for trying the code. > > On Feb 5, 7:48 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > > > In my view, what you are presuming that TerminateProcess() will always > > > be correct, regardless if the child process was successfully loaded > > > and started. > > ...or return an error. > > ... or already finished :) In this case the child process does not exit on its own; it is an infinite loop. That is the problem I was trying to address in fact: TerminateProcess returns success yet it does not work according to the documentation. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Hector Santos on 9 Feb 2010 15:39 Emil Dotchevski wrote: > On Feb 8, 7:55 am, "Paul Baker [MVP, Windows Desktop Experience]" > <paulrichardba...(a)community.nospam> wrote: >>> "Emil Dotchevski" <emildotchev...(a)gmail.com> wrote in message >>> news:823dbb82-a5e1-40ca-8d9e-fcea24415598(a)m27g2000prl.googlegroups.com... >>> Hector, thanks for trying the code. >>> On Feb 5, 7:48 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: >>>> In my view, what you are presuming that TerminateProcess() will always >>>> be correct, regardless if the child process was successfully loaded >>>> and started. >>> ...or return an error. >> ... or already finished :) > > In this case the child process does not exit on its own; it is an > infinite loop. > > That is the problem I was trying to address in fact: TerminateProcess > returns success yet it does not work according to the documentation. In my engineering opinion, you might be expecting TOO MUCH from TerminateProcess() and GetProcessExitCode(). To pull the rug from under the feet from any application, there is going to be unknowns. That is the whole point of TerminateProcess() you are terminate to KILL regardless of where it is at. To rely on GetProcessExitCode() at that point is probably unrealistic. This is not based on a SWAG, but atleast 25+ years of thousands of installation where one part of the framework relied on running customer prepared 3rd party applets, widgets, doors, CGI applications and under the cases where there was lack of response, a TerminateProcess() was called. You used a code,42, maybe that was just for example, but if its hardcoded, and then have some other part use GetProcessExitCode() with some coded reason to check the value, well, this is a part where you have to distinguish a graceful exit vs a ungraceful exit. Isn't 42 suppose to be that marker for you? The difference in our case, is that there is no expectation to kill a process as SOON as its spawn. There is a wait involved and sufficient time to give it a chance to respond. We also use a virtual I/O on the process so that is another expectation for the chid process for which to wait on. No Output, it is killed within X time. Our types of 3rd party spawns include: - 16 bit Doors - 32 bit Doors - 32 bit CGI applications (CGI, PHP, PERL, etc) For DOORS, it is mostly the console game market. Let I mentioned before, I personally don't see why you need such tight micro timing precision been starting and termination. While I can understand there is should be an straight forward functional I/O between terminatprocess and getprocessexitcode, I would not expect it to be perfect, not with a terminateprocess. I say you are expecting too much here. TerminateProcess() should be an extreme case only and one that only the parent cares about - all bets are off when you using TerminateProcess(). -- HLS
From: tanix on 9 Feb 2010 18:14 In article <eQ1TwfcqKHA.4636(a)TK2MSFTNGP06.phx.gbl>, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Emil Dotchevski wrote: > >> On Feb 8, 7:55 am, "Paul Baker [MVP, Windows Desktop Experience]" >> <paulrichardba...(a)community.nospam> wrote: >>>> "Emil Dotchevski" <emildotchev...(a)gmail.com> wrote in message >>>> news:823dbb82-a5e1-40ca-8d9e-fcea24415598(a)m27g2000prl.googlegroups.com... >>>> Hector, thanks for trying the code. >>>> On Feb 5, 7:48 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: >>>>> In my view, what you are presuming that TerminateProcess() will always >>>>> be correct, regardless if the child process was successfully loaded >>>>> and started. >>>> ...or return an error. >>> ... or already finished :) >> >> In this case the child process does not exit on its own; it is an >> infinite loop. >> >> That is the problem I was trying to address in fact: TerminateProcess >> returns success yet it does not work according to the documentation. > >In my engineering opinion, you might be expecting TOO MUCH from >TerminateProcess() and GetProcessExitCode(). > >To pull the rug from under the feet from any application, there is >going to be unknowns. That is the whole point of TerminateProcess() >you are terminate to KILL regardless of where it is at. To rely on >GetProcessExitCode() at that point is probably unrealistic. > >This is not based on a SWAG, but atleast 25+ years of thousands of >installation where one part of the framework relied on running >customer prepared 3rd party applets, widgets, doors, CGI applications >and under the cases where there was lack of response, a >TerminateProcess() was called. > >You used a code,42, maybe that was just for example, but if its >hardcoded, and then have some other part use GetProcessExitCode() with >some coded reason to check the value, well, this is a part where you >have to distinguish a graceful exit vs a ungraceful exit. Isn't 42 >suppose to be that marker for you? > >The difference in our case, is that there is no expectation to kill a >process as SOON as its spawn. There is a wait involved and sufficient >time to give it a chance to respond. We also use a virtual I/O on the >process so that is another expectation for the chid process for which >to wait on. No Output, it is killed within X time. > >Our types of 3rd party spawns include: > > - 16 bit Doors > - 32 bit Doors > - 32 bit CGI applications (CGI, PHP, PERL, etc) > >For DOORS, it is mostly the console game market. > >Let I mentioned before, I personally don't see why you need such tight >micro timing precision been starting and termination. While I can >understand there is should be an straight forward functional I/O >between terminatprocess and getprocessexitcode, I would not expect it >to be perfect, not with a terminateprocess. > >I say you are expecting too much here. TerminateProcess() should be >an extreme case only and one that only the parent cares about - all >bets are off when you using TerminateProcess(). Once you terminate a process forcefully, your system is in inconsistent state basically. Not there may be memory leaks, but if you have some named synchronization objects, you may have problems of restarting the process and getting everything in a system consistent state. The process needs to be terminated gracefully no matter what the problem is. Exceptions need to be caught in the main processing loop and loop has to be exited properly assuring a proper cleanup. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques. All collections are fully searchable down to specific chapter.
From: Emil Dotchevski on 9 Feb 2010 23:00 On Feb 8, 7:55 am, "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardba...(a)community.nospam> wrote: > > "Emil Dotchevski" <emildotchev...(a)gmail.com> wrote in message > >news:823dbb82-a5e1-40ca-8d9e-fcea24415598(a)m27g2000prl.googlegroups.com.... > > Hector, thanks for trying the code. > > On Feb 5, 7:48 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > > > In my view, what you are presuming that TerminateProcess() will always > > > be correct, regardless if the child process was successfully loaded > > > and started. > > ...or return an error. > > ... or already finished :) It's not a Cray-3 though so that's not a possibility :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Paul Baker [MVP, Windows Desktop Experience] on 10 Feb 2010 11:02
I am going to pretend I did not hear reliance on timing for synchronization, which someone has already explained is bad. Paul "Emil Dotchevski" <emildotchevski(a)gmail.com> wrote in message news:4609017e-ff59-4e5e-ac00-0a7d74002a1f(a)f17g2000prh.googlegroups.com... On Feb 3, 4:54 pm, "Nobody" <nob...(a)nobody.com> wrote: > "Emil Dotchevski" <emildotchev...(a)gmail.com> wrote in message > > news:95e9d35d-60e0-414d-81bb-cef3c12d485b(a)k2g2000pro.googlegroups.com... > > >I want to terminate a process with an exit code, and I want that exit > > code to be returned by the process being killed. Note that I can't > > synchronize with the process and I can't "wait a little" before I kill > > it. > > > On my system (XP SP3) the test below fails nearly 100% of the time. > > When it fails, the process being killed returns zero (instead of 42.) > > Is the call to TerminateProcess successful? Yes. All function calls succeed. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode |