From: kadhim AT spock DOT cs DOT colorado DOT edu (Basim Kadhim)
Subject: SIGCHLD
18 Mar 1997 14:15:48 -0800
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199703181735.KAA14373.cygnus.gnu-win32@spock.cs.colorado.edu>
Reply-To: kadhim AT cs DOT colorado DOT edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-To: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

In porting a new piece of software to GNU-Win32, I've run into what appears
to be problems with signal handling.  The program does a fork and exec
and then goes off into a loop elsewhere doing work until it detects SIGCHLD.
(I should probably mention that the loop also blocks and unblocks signals
along the way).  It appears that the process never gets the SIGCHLD
signal.  Is SIGCHLD properly supported in b17.1?

In addition, the fork and exec appear to work fine when I run under gdb
(the forked process generates the files I expect), but doesn't appear to
generate anything when I'm not running under the debugger.

The last point is a minor one.  sigaddset is defined as a macro in newlib
that just or's the right value into the set.  The problem is that it
doesn't return 0 as it should upon successful completion.  It should
probably read:

#define sigaddset(what,sig) ((*(what) |= (1<<(sig))), 0)

instead of:

#define sigaddset(what,sig) (*(what) |= (1<<(sig)))

Any clues would be much appreciated.

Basim
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".