Mail Archives: cygwin/2002/01/07/04:58:34
Hi Robert,
> On Mon, 2002-01-07 at 19:47, Michael Rumpf wrote:
>
>
> > The problem is that the signal handling of the bash is not working
correctly
> > in the C/C++ app which forks others.
>
> I'm not clear: Is the app that forks others a Cygwin app, or not?
>
> ie: as a process chain is it
> bash (cygwin)
> app1 (cygwin)
> app2 (MS CRT)
>
> or is it
> bash (cygwin)
> app1 (MS CRT)
> app2 (MS CRT)
Ok, I assume that the comment "cygwin" means that the app is linked against
cygwin runtime libs. If I got that right it is the second case:
bash (cygwin, of course)
app1 = "signals (MS CRT)"
app2 = "myclass.exe (MS CRT)" or "java myclass (???)"
> > The CTRL-C (SIGINT) terminates the app
> > after executing the signal handler in the same way CTRL-BREAK (SIGBREAK)
> > does but in opposite to the CTRL-BREAK the child processes are not taken
> > down. The forking app goes into a loop and waits for a flag to be raised
> > when the SIGINT occurs. But under bash this never happens.
>
> 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.
*snip*
>
> It's not a matter of interest. Developer time spent fixing bugs is much
> more effective that developer time spent isolating bugs. If you can
> provide clear documentation on whats occuring, then maybe we can fix it.
>
> I for one am not going to contribute 8-16 hours trying to isolate a bug
> that doesn't affect me, and that I've no motivation (per se) to solve.
I know this, sorry if phrasing to harsh. I'm not a native speaker so please
don't get me wrong, I simply don't have the time to get familiar with the
complex Cygwin internals. I would never be able to tell whether a patch will
not break other cygwin apps so it will always be some kind of quick hack...
> > > I could be wrong. Maybe
> > > someone is actively working on this. If so, I hope that person steps
> > > forward and offers some insight into how they are progressing and what
> > > their proposed fix might be.
> >
> > That would of course be great...
>
> Unfortunately, AFAIK Chris is correct. He's got a pretty good feel what
> the 'core' developers are working on :}.
>
> This doesn't affect me, but I'm willing to put a coupla hours in on it -
> starting with a clear repeatable test case - which you are part way to
> providing.
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.
Thanks a lot for investigating the issue. I will provide you any help you
need. We are around 200 developers here building a fairly huge application
server and most of the developers have to stick with the windows cmd shell
as it is inconvenient under Windows to start the Task Manager each time when
shutting down the application server in order to kill around 7 processes
manually.
We are currently using a very old version (B20.1) for our internal *build
process* and we are evaluating currently to move to a current version. It
would be great if the issue could be fixed so that we could use an updated
version of the bash to make the only but most annoying problem go away...
I have used the latest stable version of Cygwin and the bash to reproduce
the problem. The old version mentioned above is only used in the build
process of our application server...
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/
- Raw text -