aboutsummaryrefslogtreecommitdiff
path: root/lib/fatal-signal.c
diff options
context:
space:
mode:
authorBen Pfaff <blp@nicira.com>2010-03-23 15:27:44 -0700
committerBen Pfaff <blp@nicira.com>2010-03-24 16:52:07 -0700
commitc874f17fc743b38295f6059ab6554561b7555724 (patch)
tree5f64a680d4ae6adf8ab30197cacd0e929c6b7eee /lib/fatal-signal.c
parent271915d3877ab9d74836a986cb2eb483071f048b (diff)
fatal-signal: Initialize library upon any call to public function.
Not calling fatal_signal_init() means that the signal handlers don't get registered, so the process won't clean up on fatal signals. Furthermore, signal_fds[0] is then 0, which means that fatal-signal_wait() waits on stdin, so if you are testing a program interactively and accidentally type something on stdin then that program's CPU usage jumps to 100%. Since poll_block() calls fatal_signal_wait() this seems like the most reliable solution.
Diffstat (limited to 'lib/fatal-signal.c')
-rw-r--r--lib/fatal-signal.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/lib/fatal-signal.c b/lib/fatal-signal.c
index 80ecfc35..f6f913eb 100644
--- a/lib/fatal-signal.c
+++ b/lib/fatal-signal.c
@@ -137,8 +137,11 @@ fatal_signal_handler(int sig_nr)
void
fatal_signal_run(void)
{
- int sig_nr = stored_sig_nr;
+ int sig_nr;
+ fatal_signal_init();
+
+ sig_nr = stored_sig_nr;
if (sig_nr != SIG_ATOMIC_MAX) {
call_hooks(sig_nr);
@@ -152,6 +155,7 @@ fatal_signal_run(void)
void
fatal_signal_wait(void)
{
+ fatal_signal_init();
poll_fd_wait(signal_fds[0], POLLIN);
}