[project @ 1999-09-17 10:43:51 by sof]

[ghc-hetmet.git] / ghc / rts / Signals.c

diff --git a/ghc/rts/Signals.c b/ghc/rts/Signals.c
index 7062102..7214cb4 100644 (file)
--- a/ghc/rts/Signals.c
+++ b/ghc/rts/Signals.c
@@ -1,5 +1,7 @@
 /* -----------------------------------------------------------------------------
- * $Id: Signals.c,v 1.3 1999/01/26 11:12:49 simonm Exp $
+ * $Id: Signals.c,v 1.7 1999/07/14 13:39:46 simonmar Exp $
+ *
+ * (c) The GHC Team, 1998-1999
  *
  * Signal processing / handling.
  *
@@ -7,11 +9,14 @@
 
 #include "Rts.h"
 #include "SchedAPI.h"
+#include "Schedule.h"
 #include "Signals.h"
 #include "RtsUtils.h"
 #include "RtsFlags.h"
 #include "StablePriv.h"
 
+#ifndef mingw32_TARGET_OS
+
 #ifndef PAR
 
 static StgInt *handlers = NULL; /* Dynamically grown array of signal handlers */
@@ -34,21 +39,21 @@ more_handlers(I_ sig)
     I_ i;
 
     if (sig < nHandlers)
-       return;
+      return;
 
     if (handlers == NULL)
-       handlers = (I_ *) malloc((sig + 1) * sizeof(I_));
+      handlers = (I_ *) malloc((sig + 1) * sizeof(I_));
     else
-       handlers = (I_ *) realloc(handlers, (sig + 1) * sizeof(I_));
+      handlers = (I_ *) realloc(handlers, (sig + 1) * sizeof(I_));
 
     if (handlers == NULL) {
-       fflush(stdout);
-       fprintf(stderr, "VM exhausted (in more_handlers)\n");
-       exit(EXIT_FAILURE);
+      /* don't fflush(stdout); WORKAROUND bug in Linux glibc */
+      fprintf(stderr, "VM exhausted (in more_handlers)\n");
+      exit(EXIT_FAILURE);
     }
     for(i = nHandlers; i <= sig; i++)
-       /* Fill in the new slots with default actions */
-       handlers[i] = STG_SIG_DFL;
+      /* Fill in the new slots with default actions */
+      handlers[i] = STG_SIG_DFL;
 
     nHandlers = sig + 1;
 }
@@ -69,7 +74,7 @@ generic_handler(int sig)
        either.  However, we have to schedule a new thread somehow.
 
        It's probably ok to request a context switch and allow the
-       scheduler to  start the handler thread, but how to we
+       scheduler to  start the handler thread, but how do we
        communicate this to the scheduler?
 
        We need some kind of locking, but with low overhead (i.e. no
@@ -104,6 +109,8 @@ generic_handler(int sig)
     sigemptyset(&signals);
     sigaddset(&signals, sig);
     sigprocmask(SIG_UNBLOCK, &signals, NULL);
+
+    context_switch = 1;
 }
 
 /* -----------------------------------------------------------------------------
@@ -165,11 +172,13 @@ sig_install(StgInt sig, StgInt spi, StgStablePtr handler, sigset_t *mask)
        sigdelset(&userSignals, sig);
         action.sa_handler = SIG_DFL;
        break;
+
     case STG_SIG_HAN:
        handlers[sig] = (I_)handler;
        sigaddset(&userSignals, sig);
        action.sa_handler = generic_handler;
        break;
+
     default:
         barf("sig_install: bad spi");
     }
@@ -224,10 +233,10 @@ start_signal_handlers(void)
 StgInt 
 sig_install(StgInt sig, StgInt spi, StgStablePtr handler, sigset_t *mask)
 {
-    fflush(stdout);
-    fprintf(stderr,
-           "No signal handling support in a parallel implementation.\n");
-    exit(EXIT_FAILURE);
+  /* don't fflush(stdout); WORKAROUND bug in Linux glibc */
+  fprintf(stderr,
+         "No signal handling support in a parallel implementation.\n");
+  exit(EXIT_FAILURE);
 }
 
 void
@@ -235,3 +244,5 @@ start_signal_handlers(void)
 {
 }
 #endif
+
+#endif /*! mingw32_TARGET_OS */