| Re: [cdt-dev] is Win98 a supported platform ? |
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