Propblem with TerminateProcess
in [Win32 Kernel]
|
From: Jonathan de Boyne Pollard on 10 Feb 2010 16:05 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <blockquote cite="mid:f2c4d1d7-554e-452e-a786-0be0d97fd242(a)k18g2000prf.googlegroups.com" type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <p wrap="">In my view, what you are presuming that <code>TerminateProcess()</code> will always be correct, regardless if the child process was successfully loaded and started.<br> </p> </blockquote> <p wrap="">...or return an error.<br> </p> </blockquote> <p wrap="">... or already finished :)<br> </p> </blockquote> <p wrap="">It's not a Cray-3 though so that's not a possibility :)<br> </p> </blockquote> <p>Has the penny not dropped here, yet? Notice the difference that you've spotted between multiprocessor and uniprocessor machines. Think about what that means. In particular, think about what it means with respect to what thread(s) run(s) immediately after a new process (with a new main thread) has been spawned. Also think about what it means to make the thread in the parent process sleep immediately after the <code>CreateProcess()</code> call returns. Multiprogramming may be a black box, but it is not magic. There is an underlying reality of how threads are dispatched.<br> </p> </body> </html>
From: Ivo Beltchev on 11 Feb 2010 00:04 Jonathan de Boyne Pollard 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 :) >> > Has the penny not dropped here, yet? Notice the difference that you've > spotted between multiprocessor and uniprocessor machines. Think about > what that means. In particular, think about what it means with respect > to what thread(s) run(s) immediately after a new process (with a new > main thread) has been spawned. Also think about what it means to make > the thread in the parent process sleep immediately after the > |CreateProcess()| call returns. Multiprogramming may be a black box, > but it is not magic. There is an underlying reality of how threads are > dispatched. > For those not familiar with the Cray-3's awesome computing power: http://dictionary.die.net/infinite%20loop
From: Hector Santos on 11 Feb 2010 00:28 Ivo Beltchev wrote: >>>> >>> It's not a Cray-3 though so that's not a possibility :) >>> >> Has the penny not dropped here, yet? Notice the difference that >> you've spotted between multiprocessor and uniprocessor machines. Think >> about what that means. In particular, think about what it means with >> respect to what thread(s) run(s) immediately after a new process (with >> a new main thread) has been spawned. Also think about what it means >> to make the thread in the parent process sleep immediately after the >> |CreateProcess()| call returns. Multiprogramming may be a black box, >> but it is not magic. There is an underlying reality of how threads >> are dispatched. >> > > For those not familiar with the Cray-3's awesome computing power: > http://dictionary.die.net/infinite%20loop Corny and a wasted bandwidth of banter because Cray residence times are predictable. Not random. -- HLS
From: Hector Santos on 11 Feb 2010 00:31 Why are you crossing posting this? The OP didn't start with a cross post? Wasted bandwidth, in any case, at least you didn't tell him to do some thing with a banana. Jonathan de Boyne Pollard 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 :) >> > Has the penny not dropped here, yet? Notice the difference that you've > spotted between multiprocessor and uniprocessor machines. Think about > what that means. In particular, think about what it means with respect > to what thread(s) run(s) immediately after a new process (with a new > main thread) has been spawned. Also think about what it means to make > the thread in the parent process sleep immediately after the > |CreateProcess()| call returns. Multiprogramming may be a black box, > but it is not magic. There is an underlying reality of how threads are > dispatched. > -- HLS
From: James on 12 Feb 2010 12:38
"Emil Dotchevski" <emildotchevski(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.) > > Any ideas? [...] Create a remote thread in the process and wait for it to quit. The act of the remote thread starting and quitting should indicate that the process has been initialized? |