-
sof authored
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 :)
30a97b4c