-/* NOTE [io-manager-ghci]
-
- When GHCi loads the base package, it gets another copy of the CAFs
- in GHC.Conc that record the IO manager's ThreadId, and the blocking
- queues, so we get another IO manager. This is bad enough, but what
- is worse is that GHCi by default reverts all CAFs on every :load,
- so we'll get *another* IO manager thread (and an associated pipe)
- every time the user does :load. Miraculously, this actually
- manages to just about work in GHC 6.10 and earlier, but broke when
- I tried to fix #1185 (restarting the IO manager after a fork()).
-
- To work around it and ensure that we only have a single IO manager,
- we map the CAFs in the dynamically-loaded GHC.Conc to the
- statically-linked GHC.Conc. This is an ugly hack, but it's the
- least ugly hack that I could think of (SDM 3/11/2009)
-*/
-
-#define RTS_GHC_CONC_SYMBOLS \
- SymI_NeedsProto(base_GHCziConc_pendingDelays_closure) \
- SymI_NeedsProto(base_GHCziConc_pendingEvents_closure) \
- SymI_NeedsProto(base_GHCziConc_ioManagerThread_closure)
-
-#ifdef mingw32_HOST_OS
-#define RTS_GHC_CONC_OS_SYMBOLS /* empty */
-#else
-#define RTS_GHC_CONC_OS_SYMBOLS \
- SymI_NeedsProto(base_GHCziConc_prodding_closure) \
- SymI_NeedsProto(base_GHCziConc_sync_closure) \
- SymI_NeedsProto(base_GHCziConc_stick_closure)
-#endif
-