[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] is Win98 a supported platform ?
|
Hi,
Wait, there was one more change I've had to make.
We have a non-cygwin app that we spawn from Eclipse and that catches the
CTRL-C event but not the CTRL-BREAK NT console event. I've also modified
starter.cpp to send CTRL_BREAK_EVENT in addition to CTRL_C_EVENT for
WAIT_OBJECT_0 + 2 requests from the spawner.
In the end, an app that caught both of these would just not work right, but
sending both is modestly safer than just sending one.
Thanks!
-Chris
At 12:33 PM 4/22/2003 -0700, you wrote:
Hi!
So we are looking at the solution to enhance Spawner
public native static raise(int pid, int sig);
or
public native static raise(Object pid, int sig);
To interrupt the program, will that be harmfull in your enviroment?
instead of the dropping the SIGINT to gdb?
The difference here is the change in visbility to raise? That fine,
details below.
Before people nod off in the details, let me suggest that anything having
to do with signals is going to still be a nightmare on NT/cygwin
solutions. What would be more OS neutral is if GDB could keep polling the
mi input stream while the target is running so we could send a request to
ask for a stop through the normal channel without having to do all this
signal/interrupt stuff.
I've essentially made three changes to spawner and the related classes: (I
get stuck with this since no one likes to mess with it -- woe is me.)
1) Added some new methods and changed interfaces in ProcessFactory,
Spawner and the spawner native methods to support a new priority parameter
in create and a new setPriority method in Spawner.
2) Added some new methods and changed interfaces in ProcessFactory,
Spawner and the spawner native methods to support a new cygwin parameter
for process creation causing spawner.dll to use a different starter.
3) Added a new cygwin-linked starter (called cygstarter) that translates
requests on event WAIT_OBJECT_0 + 2 (sent from spawner.dll) into cygwin
raise calls rather than NT GenerateConsoleCtrlEvent calls. I do this
because the CtrlEvents are caught by our cygwin version and ignored unless
the receiving process is the head of the NT process group and, of course,
the starter is the head of the process group rather than the child that
the starter started.
Thanks!
-Chris
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
