Re: bash/cmd CTRL-C problem...

["Michael Rumpf" <michael@rumpfonline.de>]

> Yes, that is what I meant.
>
> > bash (cygwin, of course)
> > app1 = "signals (MS CRT)"
> > app2 = "myclass.exe (MS CRT)" or "java myclass (???)"
>
> Lets leave java to the side. If we solve it with MS CRT, and java apps
> still have problems, then that becomes a new bug. Why? because there are
> multiple JVM's to consider, making it harder to setup a test
> environment. And because I suspect that a solution to one will solve the
> other.

OK, no problem. Java processes are created and they can be taken down by
sending them CTRL-BREAK signals (You need to start the Sun VM with
parameter -Xrs to make this work, otherwise you will just see a thread dump
because the standard VM establishes a SIGBREAK handler which prints stack
dumps of all running threads)

> > > By this are you implying that this:
> > > cmd.exe
> > > app1 (cygwin/MS CRT (see above))
> > > app2 (MS CRT)
> > > behaves as you expect?
> >
> > cmd.exe
> > bash (cygwin, of course)
> > app1="signals (MS CRT)"     app1
> > app2="myclass.exe (MS CRT)" or "java myclass (???)"
> >
> > yes here the behaviour is correct !! When pressing CTRL-C the
> execution
> > continues after handling the signal. The child apps are taken down by
> > sending a CTRL-BREAK event.
>
> Ok. let me confirm I understand everything.
>
> * Failure case *
> 1) double click on a shortcut to cygwin.bat from a default install of
> cygwin
> 2) run ./signals.exe
> 3) ./myclass.exe is automatically executed (BTW: this is not fork()  -
> fork() requires a cygwin linked signals.exe. In unix terms, this is a
> spawned program.
> 4) Hit CTRL-C.
> 5) The user is returned to the bash shell started via 1), but
> myclass.exe is left running.
>
> * success case *
> 1) double click on a shortcut to cmd.exe
> 2) run X:\cygwin\cygwin.bat

No. I do not run cygwin.bat ! It is just pure cmd.exe !!!

> 3) run ./signals.exe
> 4) ./myclass.exe is automatically executed (BTW: this is not fork()  -
> fork() requires a cygwin linked signals.exe. In unix terms, this is a
> spawned program.

OK, myclass.exe is spawned program...

> 5) Hit CTRL-C.
> 6) The user is returned to the bash shell started via 2), and
> myclass.exe is terminated correctly.

The user is returned to the cmd.exe shell started via 1) and myclass.exe is
terminated correctly.

> Please edit the above as needed to correctly show the actions taken and
> the expected outcome, to prevent me erroneously reporting no-fault-found
> or no-success-found etc.
>
> > Great, the attachment of one of my previous mails should give you a
> > repeatable test case at hand. It includes the signals.cpp (app1),
> > myclass.cpp/myclass.java (app2) and a Makefile to compile it (the
> makefile
> > needs some updates to the paths used there). You don't have to compile
> the
> > Java class just compile the C/C++ apps and launch "signals cpp" which
> > results in forking the C/C++ child app myclass.exe.
>
> I've not archived those mails. Can you please send me (as an off-list
> email, separate to your on-list response) the relevant files. I presume
> they will build with gcc -mno-cygwin ? (If Visual C++ is required to
> build them, please provide a .exe).

I have no Makefile for compiling the test case with gcc at hand. The general
opinion here at my company is that the code generated by gcc is too slow. So
we are using the native compilers under the different platforms. The
decision to use the native compilers has been made a few years ago and I
guess a lot has changed since then, but we have decided last year to move to
Java and so adapting everything to gcc would be a one year effort which
nobody wants to invest because we have finally decided to move to Java
completely. This is also not a single step task and until that has not been
achieved many of the building blocks, like the app server launcher, remains
in C++

AIX -> xlC_r
NT/IA64 -> cl.exe
Linux -> GCC
HPUX -> aCC
Solaris -> CC

Michael



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/