[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Win32 spawner
|
I remember seeing something like that in the code. It might
still be there but maybe not used correctly?? not sure.
And, yes, we're Win2K and later. We dropped support for
NT/9x/ME quite a while ago.
Cheers,
Doug.
I've used the Win32 Job API in the past to terminate a process
and its children. The Job API is only present on Win2K, Windows XP and above.
Not sure if CDT is still trying to maintain support for Windows versions
earlier than 2K...
The basic idea is that a Job object is created prior
to calling CreateProcess using CreateJobObject(). The new process is started
in the suspended state and assigned to the job object using
AssignProcessToJobObject(). Then the newly-created process is resumed using
ResumeThread().
When it's time to terminate the process,
TerminateJobObject() is used instead of TerminateProcess(). The orignal
process and any child processes are terminated.
Again, not sure if it's
applicable, but an idea nonetheless...
Cheers,
Matthew
On Thu, Jul 17, 2008 at 7:51 AM, John Cortell <
john.cortell@xxxxxxxxxxxxx>
wrote:
A quick experiment and some archived emails reminded me of why I stayed
away from java.lang.Runtime.exec() three years ago. It unconditionally
specifies TRUE for the "inherit handles?" parameter to the Win32
CreateProcess() call. Spawner's launch logic specifies FALSE. The TRUE
parameter is a deal breaker for us. Inheriting handles prevents CORBA
interaction between parent and child; apparently interacting CORBA
components require independent system handles.
John
At 04:44 PM 7/16/2008, Schaefer, Doug
wrote:
Content-class:
urn:content-classes:message
Content-Type:
multipart/alternative;
boundary="----_=_NextPart_001_01C8E78D.335F53D0"
Good question. I think it has
something to do with allowing the child process to clean up. Also,
TerminateProcess only kills that process, not the children of that
process. But I think there is a way to do that too, but it involves a lot
of code.
Feel free to try
and improve it. It probably needs it. Just make sure you don't break gdb
spawning :)
BTW, I've worked a little over the past go get everything
that doesn't need the spawner's signaling capability off of it and onto
Java's Runtime.exec. It seems to work better in certain
situations.
Cheers,
Doug.
- From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John
Cortell
- Sent: Wednesday, July 16, 2008 4:36
PM
- To: CDT General developers list.
- Subject: [cdt-dev] Win32
spawner
- I've been trying to figure out why Spawner.kill() isn't killing a
process for us. The "process", in our case, is our debugger engine--a
Win32 executable. We use the spawner to launch it, and on
shutdown, we sometimes need to abruptly kill it (if it's taking
too long to shut down gracefully). Again, calling kill() on the Process
object, which is a Spawner, isn't doing the trick.
- I found the answer in starter.cpp. It contains a handler which waits
for the terminate event-handle to be signaled and then goes about trying
to kill the process it earlier created. Problem is: it does so by
sending a console CTRL-C event (unless it's a cygwin process, in which
case it runs a "kill -SIGTERM" command). In our case, the process is not
a cygwin process. The CTRL-C event isn't doing the trick, and I have to
wonder...why aren't we just using the TerminateProcess Win32 function?
We have the process handle, after all. I've coded it and it's working.
I'm just scratching my head wondering why we'd try sending a CTRL-C
instead.
- John
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev