Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <024f01c19786$4a4dd070$c51811ac@brokat.de>
From: "Michael Rumpf" <michael AT rumpfonline DOT de>
To: <cygwin AT cygwin DOT com>
References: <00f201c18922$2783b180$c51811ac AT brokat DOT de><003c01c18936$55ca5fd0$c51811ac AT brokat DOT de><05cb01c18a07$85d72c40$c51811ac AT brokat DOT de><02f701c19516$5212afa0$c51811ac AT brokat DOT de><20020104170443 DOT GD30445 AT redhat DOT com> <00dc01c19758$02b30f10$c51811ac AT brokat DOT de> <1010394535 DOT 566 DOT 10 DOT camel AT lifelesswks> <011401c19762$04185fe0$c51811ac AT brokat DOT de> <000f01c19766$549cb8e0$0200a8c0 AT lifelesswks> <017b01c1976a$21451e70$c51811ac AT brokat DOT de> <007b01c1977d$6093f520$0200a8c0 AT lifelesswks>
Subject: Re: please review my logic Re: bash/cmd CTRL-C problem...
Date: Mon, 7 Jan 2002 15:19:17 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

> Ok.
> I didn't realise that signal() is implemented in the standard VC++
> libraries.
> Can you tell me any details of the signal implementation you are using
> on win32?
> If you wished to follow clean room r/e for this, I can implement the
> signal sending side to match up with what your library expects.
>
> Also, according to
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9
> 8/HTML/_crt_signal.asp
>

I tried this with the signal() function as well as with the
SetConsoleCtrlHandler() function
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/co
nchar_599u.asp). The only difference was that the integer identifying the
signal was different but in both cases but the behaviour was the same. That
is the reason why I view these two ways of implementing the signal handling
equivalent (I returned TRUE from the HandlerRoutine to indicate that the
signal was handled and that no default action, like for example process
termination should happen, but that did not change anything)

> SIGINT is not supported for win32 programs. I quote:
> "Note SIGINT is not supported for any Win32 application including
> Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32
> operating systems generate a new thread to specifically handle that
> interrupt. This can cause a single-thread application such as UNIX, to
> become multithreaded, resulting in unexpected behavior. "

I don't know how signals are treated/implemented in UNIX and what is maybe
wrong with the approach of starting a new thread, so I must admit that I'm
sure on how to interpret the statement above...

> As for why you see the current behaviour, I'm a little mystified.
>
> Here's why:
>
> Firstly, here's a snippet of the output of a strace of kill -2
> <signals.exe pid>
>
>  2149 2816627 [main] kill 920 _kill: kill (3656, 2)
>  1542 2818169 [main] kill 920 sig_send: pid 3656, signal 2, its_me 0
>  1387 2819556 [main] kill 920 getsem: pid 3656, ppid 3648, wait 1000,
> initializing 0
>  1776 2821332 [main] kill 920 sig_send: Not waiting for sigcomplete.
> its_me 0 signal 2
>  3817 2825149 [main] kill 920 sig_send: returning 0 from sending signal
> 2
>  2529 2827678 [main] kill 920 kill_worker: 0 = kill_worker (3656, 2)
>
> The getsem line is whats interesting: This is retrieving the semaphore
> used to syncronise the signalling across process's.
>
> It succeeds! (I'm running a slightly modified cygwin here, which as the
> patch at the end of this email shows (in combination with the source :})
> should always indicate if there is an error).

The signal is correctly recieved by the app signal.exe, that is not the
problem. The problem is that the code after the loop (Line 139)

while(loop)
    Sleep(DWORD) 1000);

printf("\n>>> signals: Finished waiting now...\n");   // !!!!!!!!!!!!!! no
executed !!!!!!!!!!!!

is not executed. Therefore I can't shutdown any child processes correctly.
Under cmd.exe the printf line gets executed and I can see the output in the
console window....

> It shouldn't succeed - Sysinternals process explorer shows signals.exe
> as having no semaphores at all, let alone a named semaphore with the
> correct name.
>
> further investigation finds that bash has got the semaphore for the
> process pid that signals has, and that Ctrl-C is actually being recieved
> by bash, which is running as a sub-process.
>
> Doing a ps in another bash shell will show /path/to/signals against a
> PID that if you look up in the windows PID list is actually bash. Cygwin
> is pretending that signals.exe is a cygwin app via the use of a dummy
> bash process, that has called exec(), but is kept around to recieve
> signals etc...
>
> So here's my best guess as to whats happening:
> When you hit CTRL-C, it propogates to
> signals.exe (handled as you expect)
> bash.exe (still attached to the console and gets handled via default
> signal handler - exit and terminate all subprocess's - which kills
> signals.exe)
>
> If you have time, and wanted to test this, you could make a three level
> test program. I would appreciate if you could do this as it be an
> independent confirmation of the analysis.
> outer level - recieved CTRL-C, prints that it's got it, and
> quits(without terminateding signals.exe).
> middle level - signals.exe
> inner level - myclass.exe.
>
> I'd expect that you'd see the outer level get killed in the same fashion
> as you currently see signals.exe die. the middle level would run and
> kill myclass correctly.

I'm not sure why signal.exe should run when outer.exe gets a CTRL-C event.
This is just another level...
Nevertheless, I created a program called outer.exe which spawns signals.exe
which in turn spawns myclass.exe.
When I press CTRL-C outer.exe is terminated without executing any other code
in outer.exe.
See the source of outer.cpp Line 106 the text ">>> outer: Finished waiting
now. Termintaing..." should be printed to the console after pressing CTRL-C.
But this does not happen...

Michael

PS: I send you the source and the binary seperately...


--
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/