Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <4.3.2.7.0.20001001212519.00c09bb0@pop>
X-Sender: cabbey AT pop (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 01 Oct 2000 22:41:28 -0500
To: cygwin AT sourceware DOT cygnus DOT com
From: Chris Abbey <cabbey AT bresnanlink DOT net>
Subject: signals?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Does anyone out there really understand signal handling in cygwin?

I'm starting to suspect it is not like any other *nix platform I've
worked on... and it's really starting to get in my way. :(

Here's the situation... I have a win32 application that has a signal
handler registered for SIGQUIT. Running the application from cmd.exe
(I'm on NT4) and then using ctrl-break to send a SIGQUIT (or selecting
it from the task manager and clicking kill job, then cancel on the
dialog that says it hasn't exited yet) will result in the signal handler
taking over and dumping a bunch of information about the process' status
to stdout then the application's normal function resumes. This all works
fine, and you can do this hundreds of thousands of times without any
problem. The same application under Linux or AIX behaves the same way.
(except that it's ctrl-\ or kill -QUIT <pid> to send the signal)

Enter cygwin.

ctrl-\ does nothing (ok, that's a shell-ism so no big deal...)

ctrl-break signals the child process and it begins to work, but
   almost immediately the process is terminated. close, but not
   quite there.... :(

kill -QUIT kills the process with a message "Quit (core dumped)"
   and produces a "stackdump" file.

I've tried various other tricks for launching the process, including
nohup, cmd /c, start... none come as close as ctrl-break, where our
signal handler is at least called. it also doesn't seem to matter
what shell is being used, bash and sh both behave the same.

I've read the programmer's guide entry about signals, which includes
the following:

"When a process notices it has a signal, it scans its signal bitmask
and handles the signal in the appropriate fashion."

anyone know how I can manipulate this mask? or the "appropriate"
handling choices?

I really suspect that the problem is that the child process registers
for signals via the win32 API, not the cygwin API. Is there any way I
can work around this? Any suggestions welcomed, as I said this is really
getting annoying.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com