public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: Tom Sanders <developer_linux@yahoo.com>,
	redhat-list@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Question about Linux signal handling
Date: Sun, 23 Feb 2003 10:30:07 -0600	[thread overview]
Message-ID: <03022310300700.31584@tabby> (raw)
In-Reply-To: <20030223044520.87268.qmail@web9804.mail.yahoo.com>

On Saturday 22 February 2003 22:45, Tom Sanders wrote:
> If I catch a signal (SIGUSR2) using "sigaction" call
> then is the signal handler replaced with default
> handling, if I don't install the signal handler again?
>
> I remember that in UNIX "signal" system call default
> signal bahavior was to replace the signal handler with
> default after everytime signal was received?
>
> My observation is that even if I get same signal
> twice, I get the same print (which I have in my signal
> handler) again, illustrating that signal handler was
> not replaced with default !!! Is that the correct
> behavior of "sigaction"?

Depends on the value of sa_flags parameter:

>From the manpage SIGACTION(2):

       sa_flags  specifies  a  set  of  flags  which  modify  the
       behaviour  of the signal handling process. It is formed by
       the bitwise OR of zero or more of the following:
 
              SA_NOCLDSTOP
                     If signum is SIGCHLD, do not receive notifi-
                     cation when child processes stop (i.e., when
                     child  processes  receive  one  of  SIGSTOP,
                     SIGTSTP, SIGTTIN or SIGTTOU).
 
              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.)
 
              SA_RESTART
                     Provide behaviour compatible with BSD signal
                     semantics  by  making  certain  system calls
                     restartable across signals.
 
              SA_NOMASK or SA_NODEFER
                     Do  not  prevent  the  signal   from   being
                     received from within its own signal handler.
 
              SA_SIGINFO
                     The signal handler takes  3  arguments,  not
                     one.   In  this case, sa_sigaction should be
                     set instead of sa_handler.   (The  sa_sigac-
                     tion field was added in Linux 2.1.86.)

You are describing SA_ONESHOT as what you think you should
get..

I believe you are getting the correct result. With the ONESHOT option
you can/will loose signals, since the handler would be set back to the
default, and any subsequent signal lost. This loss of signals is one of the
original complaints about UNIX signal handling.

Now my manpage continues with the warning:

       The  POSIX  spec  only defines SA_NOCLDSTOP.  Use of other
       sa_flags is non-portable.

and:

CONFORMING TO
       POSIX,  SVr4.  SVr4 does not document the EINTR condition.

  reply	other threads:[~2003-02-23 16:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-23  4:45 Question about Linux signal handling Tom Sanders
2003-02-23 16:30 ` Jesse Pollard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-23 22:29 Albert Cahalan
2003-02-23 23:43 ` Alan Cox
2003-02-23 23:04   ` Albert Cahalan
2003-02-24  0:20     ` Alan Cox
2003-02-24  0:01   ` Magnus Danielson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=03022310300700.31584@tabby \
    --to=jesse@cats-chateau.net \
    --cc=developer_linux@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=redhat-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox