[project @ 2002-04-23 06:34:26 by sof]
authorsof <unknown>
Tue, 23 Apr 2002 06:34:27 +0000 (06:34 +0000)
committersof <unknown>
Tue, 23 Apr 2002 06:34:27 +0000 (06:34 +0000)
commit30a97b4c93f639ac168b2cc30bb1f490198dc339
tree0d58d31010819641f161ed6b353472a7e490670f
parent80e7e33a1834aac9497a057d9213c87fb9417fbd
[project @ 2002-04-23 06:34:26 by sof]
More sched_mutex related cleanup & fixes; little bit
too delicate for my liking, this.

* Revert lock assumptions for raiseAsync(); now assumed
  to run with sched_mutex held (as it mucks about with a
  TSO).
* stodgily release / acquire sched_mutex around calls
  to startSignalHandlers() (as is done in Signals.c)
* in the presence of user-installed signal handlers, the
  MT-enabled RTS failed to shutdown -- all queues empty
  causes a lone RTS worker thread to pause() waiting for
  signals. This is not the right thing to do; I (temporarily?)
  disabled this signal-wait fallback in MT mode and shut
  down instead. We need to be clearer as to what is a shutdown
  condition in MT mode.

* The use of sched_mutex to protect next_thread_id increments
  is causing headaches; disabled in non-SMP mode right now until
  I've figured out the pthreads-correct way of doing atomic
  increments.

* There's still a ^C-related problem which causes the Haskell
  handler to sometimes induce a SEGV when run. Feel free to debug :)
ghc/rts/Exception.hc
ghc/rts/GC.c
ghc/rts/Schedule.c