All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] question about signal handling in tst_sig()
Date: Mon, 14 Mar 2016 14:43:21 +0100	[thread overview]
Message-ID: <20160314134321.GD600@rei.lan> (raw)
In-Reply-To: <20160314132827.GC600@rei.lan>

Hi!
> > Looks like in tst_sig(), if _SC_SIGRT_MIN defined, all realtime signals
> > won't be set an handler:
> > 
> > 125 #ifdef _SC_SIGRT_MIN
> > 126                 if (sig >= sigrtmin && sig <= sigrtmax)
> > 127                         continue;
> > 128 #endif
> > 
> > but, if it wasn't defined, then all realtime signals will be set an
> > handler:
> > 
> > 134 #if !defined(_SC_SIGRT_MIN) && defined(__SIGRTMIN) &&
> > defined(__SIGRTMAX)
> > 135                         /* Ignore all real-time signals */
> > 136                 case __SIGRTMIN:
> > 137                 case __SIGRTMIN + 1:
> > ...

And also there is a break down after the long list of cases.


So it looks like:

* if _SC_SIGRT_MIN is defined we have a POSIX compilant system
  and we skip realtime signals in the if at line 125.

* Otherwise if system is not POSIX compilant but __SIGRTMIN and
  __SIGRTMAX is defined, we skip them in the hack in the switch()

  this is possibly workaround for old glibc without _SC_SIGRT_MIN
  support

> > is that correct, or I missed something here? 
> 
> The loop goes over signal numbers from 1 to NSIG (which is defined in
> system headers). Supposedly when _SC_SIGRT_MIN is not defined the system
> does not support realtime signals and the NSIG has value of the highest
> allocated (non-realtime) signal number.
> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz
> 
> -- 
> Mailing list info: http://lists.linux.it/listinfo/ltp

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2016-03-14 13:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14  8:19 [LTP] question about signal handling in tst_sig() Han Pingtian
2016-03-14 13:28 ` Cyril Hrubis
2016-03-14 13:43   ` Cyril Hrubis [this message]
2016-03-15  1:28     ` Han Pingtian

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=20160314134321.GD600@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.