|
Hi,
The main problem is that the following requirement
must be satisfied:
- the process that issues GenerateConsoleCtrlEvent
must be a member of the group it wants to affect.
According to your finding, to process control event
properly, cygwin must be a group leader. In this case process who launched
it cannot belong to the same console group. So it cannot emit control event to
the members of the new group.
There is a simple and effective solution
for this problem - to use function CreateJobObject. In this case we can get
rid of starter.exe at all. But I'm limited with compatibility requirement (this
function does not exist in NT 4 and Windows ME).
So I cannot give a solution from the top of my
head, but I'll try to find something to fix the problem.
Alex Chapiro
----- Original Message -----
Sent: Tuesday, February 04, 2003 12:03
PM
Subject: 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
_______________________________________________ cdt-dev mailing
list cdt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/cdt-dev
|
