[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Win32 spawner
|
Ah, yes, we had the GetProcAddress to support older
versions of Windows. I guess August was when we dropped it.
:)
To be honest I remember being very confused going through
that code. I didn't really know what job objects were. And I was working on that
cygwin 'kill' kludge so I may just as easily broke something than fixed it. But
maybe I got luckly ;).
Cheers,
Doug.
Thanks. The spawner code already creates a Job object and assigns
the project to is (I've attached starter.cpp for reference). To handle a kill,
the code first sends a CTRL-C to the program then does a TerminateJobObject.
That doesn't kill our process, though.
Taking a closer look, I see
that Doug revised the code last August to not use GetProcAddress to get the
job API pointers. The commit message says the wrong function names were being
used. We're on CDT 4.X so we don't have the change. I wonder if that's why the
job functions aren't working.
I'll update our version to have Doug's
change and report back if it made a difference. BTW, I have since changed our
program (debugger engine) to handle the CTRL-C and now the spawner kill does
the job. But I'll look into this job thing as a possible alternate
resolution.
John
At 09:45 AM 7/17/2008, Matthew Ballance
wrote:
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
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@xxxxxxxxxxx
- https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
