[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Starter.exe
|
Hi!
You inspired me to check. I produced two different exe's, one with
DevStudio, with cygwin. If I run the following snippet of code using the
Spawner, I see caught signals with my DevStudio app and not-caught
signals with cygwin app, though both work normally from the command
console when I hit Ctl-C.
while(
true
)
{
try
{
Process
process = ProcessFactory.getFactory().exec(
"c:\\foo.exe");
if(
process
instanceof
Spawner )
{
Spawner
spawner = (Spawner)process;
while(
true
)
spawner.interrupt();
}
}
catch(
IOException e )
{}
}
It's definitely cygwin. At the moment I am thinking that unless I
can find a better version of cygwin I'm going to have to have two
starter.exe's, one a cygwin app for interrupting cygwin launches and one
starter.exe for non-cygwin apps. Gah!
Here's the devstudio code:
// foo.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <Windows.h>
void test(char *str)
{
FILE *fp = fopen( "C:\\foo.log", "a" );
if( fp != 0 ) {
fprintf( fp, str );
}
fclose( fp );
}
BOOL WINAPI HandlerRoutine( DWORD dwCtrlType) //
control signal type
{
BOOL ret =
TRUE;
switch(dwCtrlType)
{
case
CTRL_C_EVENT:
test(
"here\n" );
break;
case
CTRL_BREAK_EVENT:
break;
case
CTRL_CLOSE_EVENT:
ret
= FALSE;
break;
case
CTRL_LOGOFF_EVENT:
ret
= FALSE;
break;
case
CTRL_SHUTDOWN_EVENT:
ret
= FALSE;
break;
default:
break;
}
return
ret;
}
int main(int argc, char* argv[])
{
int i =
0;
SetConsoleCtrlHandler(
HandlerRoutine, true );
test(
"starting\n" );
while( 1
)
;
return
0;
}
Here's the cygwin code:
#include <signal.h>
#include <stdio.h>
void test(char *str)
{
FILE *fp = fopen( "C:\\foo.log", "a" );
if( fp != 0 ) {
fprintf( fp, str );
}
fclose( fp );
}
void dispatch(int sig)
{
test( "caught
signal\n" );
}
main()
{
test( "starting\n"
);
signal( SIGINT, dispatch
);
while( 1 )
sleep( 1 );
}
I suppose it's not that bad since I already have private code for
org.eclipse.core.win32|solaris|linux to support the setpri entry
points.
Thanks!
-Chris
At 08:03 AM 2/4/2003 -0500, you wrote:
Actually in Win priority range for
the threads has 31 level.
Starter exists because of GenerateConsoleCtrlEvent causes Ctrl event
(Ctrl-C
for example) to come to all process in the target group. So using
this
function in spawner causes that javaw process itself gets this
event.
starter is a leader of new group and protects javaw.
I don't see any problem to transmit priority setting or any other
command
through starter to launched process.
I'll check if in cygwin Ctrl-C doesn't work. So far I haven't gotten
any
complains about that. Thanks for the information.
Alex Chapiro
----- Original Message -----
From: "Chris Songer" <songer@xxxxxxxxxxxxx>
To: <cdt-dev@xxxxxxxxxxx>
Sent: Monday, February 03, 2003 11:04 PM
Subject: [cdt-dev] Starter.exe
> Hi!
>
> The real challenge with all of this setpri stuff is the starter.exe
for
NT.
> Everything else is just easy. Does anyone have any background on
why
> starter.exe is there? Is it because you need to have something to be
the
> head of a process group for NT's GenerateConsoleCtrlEvent to work?
That's
> my suspicion.
>
> If so, it does not appear to interoperate well with cygwin and I
think it
> will only work for Ctrl events on non-cygwin apps. So not only is
it
> screwing me over for setting priority ( going to have to create an
event
to
> send it since the pid held in spawner.dll is for starter and not
what
> starter started ) but it's ALSO not working for cygwin apps since
cygwin
> has to be the process group leader before it will turn a
CTRL_C_EVENT into
> a SIGINT.
>
> Thanks!
> -Chris
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
>
http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev