This is the mail archive of the
cygwin-developers@sources.redhat.com
mailing list for the Cygwin project.
Re: testsuite signal handling patch
- To: Chris Faylor <cygwin-developers at sources dot redhat dot com>
- Subject: Re: testsuite signal handling patch
- From: Egor Duda <deo at logos-m dot ru>
- Date: Mon, 4 Sep 2000 21:41:11 +0400
- Organization: DEO
- References: <51226485839.20000904131022@logos-m.ru><147231928395.20000904144106@logos-m.ru> <20000904131036.A24177@cygnus.com>
- Reply-To: Egor Duda <cygwin-developers at sources dot redhat dot com>
Hi!
Monday, 04 September, 2000 Chris Faylor cgf@cygnus.com wrote:
CF> On Mon, Sep 04, 2000 at 02:41:06PM +0400, Egor Duda wrote:
>>Monday, 04 September, 2000 Egor Duda deo@logos-m.ru wrote:
>>ED> currently, tests from winsup.api/ltp/ can possibly catch fatal
>>ED> signals such as SIGSEGV recursively. attached patch fixes this.
>>
>>btw, shouldn't call_handler() set signal handler to SIG_DFL while
>>program is in handler?
CF> No.
to be more precise, "... if handler was set with signal() call or
sigaction call with appropriate flag?"
linux man page for sigaction contains the followin text:
===============================================================
...
SA_ONESHOT or SA_RESETHAND
Restore the signal action to the default
state once the signal handler has been
called. (This is the default behavior of
the signal(2) system call.)
===============================================================
glibc doc, otoh, says that signal which is currently handled
should be blocked. susv2 says nothing specific. maybe someone
quote what posix or ansi say about this?
Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19