sakib mondal wrote:
> Of the existing active mailing lists, I thought this is the list where I can
> get help on my problem.
This list is for networking issues. Try linux-c-programming@vger.kernel.org.
> I am facing the problem of intermittent signal loss in RH (2.4.18-3). The
> program runs in a loop, and is able to respond to individual signals
> (SIGUSR1 and SIGUSR2). In fact, it works well with multiple occurence of the
> same signal. However, if SIGUSR2 is sent after SIGUSR1, the program responds
> to the SIGUSR1, but does not respond to SIGUSR2. It is to be noted that if a
> SIGUSR1 is raised before SIGUSR2, the behaviour is normal. I shall
> appreciate any pointer to why this is happening.
> The code snippet is given below.
>
> static void signal_handler(int num)
> {
>
> if (signal(num, signal_handler) == SIG_ERR) {
> syserr_quit("Unable to install signal handler");
> }
Avoid using signal() for non-trivial cases; use sigaction() instead.
Note that the default behaviour of signal() in GNU libc 2.x is to use
the BSD semantics; i.e. signal handlers *aren't* removed when the
signal is received. However, signal() may have SysV semantics
depending upon which feature-test macros (_USE_<feature>) are defined,
so it's safest to just use sigaction() instead.
Also, if you use the same signal handler for multiple signals, bear in
mind that the handler may be re-entered if the second signal is
received before the handler has finished handling the first signal.
Also bear in mind that not all library functions are safe to call from
within a signal handler. Ideally, you should only use functions whose
documentation explicitly states that they may be called from within a
signal handler. Unfortunately, I don't recall having actually seen
such a statement for any of the standard libc functions.
I suggest that you read the "Signal Handling" section of the "libc"
Info file for more information, particularly the "Nonreentrancy" node.
--
Glynn Clements <glynn.clements@virgin.net>
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
