[project @ 2001-08-07 20:10:30 by ken]
authorken <unknown>
Tue, 7 Aug 2001 20:10:30 +0000 (20:10 +0000)
committerken <unknown>
Tue, 7 Aug 2001 20:10:30 +0000 (20:10 +0000)
Back up previous change, which was not really a fix of any bug, let alone
the bug it seemed to have fixed.

ghc/rts/Main.c

index 582a932..41f9d99 100644 (file)
@@ -1,5 +1,5 @@
 /* -----------------------------------------------------------------------------
- * $Id: Main.c,v 1.28 2001/07/26 03:20:52 ken Exp $
+ * $Id: Main.c,v 1.29 2001/08/07 20:10:30 ken Exp $
  *
  * (c) The GHC Team 1998-2000
  *
 # include <windows.h>
 #endif
 
-#ifdef HAVE_TIME_H
-# include <time.h>
-#endif
-
 extern void __init_PrelMain(void);
 
 /* Hack: we assume that we're building a batch-mode system unless 
@@ -54,17 +50,6 @@ int main(int argc, char *argv[])
     SchedulerStatus status;
     /* all GranSim/GUM init is done in startupHaskell; sets IAmMainThread! */
 
-    /*
-     * Believe it or not, calling tzset() at startup seems to get rid of
-     * a scheduler-related Heisenbug on alpha-dec-osf3.  The symptom of
-     * the bug is that, when the load on the machine is high or when
-     * there are many threads, the variable "Capability *cap" in the
-     * function "schedule" in the file "Schedule.c" magically becomes
-     * null before the line "t = cap->rCurrentTSO;".  Why, and why does
-     * calling tzset() here seem to fix it?  Excellent questions!
-     */
-    tzset();
-
     startupHaskell(argc,argv,__init_PrelMain);
 
     /* kick off the computation by creating the main thread with a pointer