-lnat total_ticks = 0;
-
-/* ticks left before next pre-emptive context switch */
-int ticks_to_ctxt_switch = 0;
-
-/* -----------------------------------------------------------------------------
- Tick handler
-
- We use the ticker for time profiling.
-
- SMP note: this signal could be delivered to *any* thread. We have
- to ensure that it doesn't matter which thread actually runs the
- signal handler.
- -------------------------------------------------------------------------- */
-
-static
-void
-#if defined(mingw32_TARGET_OS) || (defined(cygwin32_TARGET_OS) && !defined(HAVE_SETITIMER))
-
-CALLBACK
-handle_tick(UINT uID STG_UNUSED, UINT uMsg STG_UNUSED, DWORD dwUser STG_UNUSED,
- DWORD dw1 STG_UNUSED, DWORD d STG_UNUSED)
-#else
-handle_tick(int unused STG_UNUSED)
-#endif
-{
- total_ticks++;
-
-#ifdef PROFILING
- handleProfTick();
-#endif
-
- if (RtsFlags.ConcFlags.ctxtSwitchTicks > 0) {
- ticks_to_ctxt_switch--;
- if (ticks_to_ctxt_switch <= 0) {
- ticks_to_ctxt_switch = RtsFlags.ConcFlags.ctxtSwitchTicks;
- context_switch = 1; /* schedule a context switch */
- }
- }
-}
-
-
-/*
- * Handling timer events under cygwin32 is not done with signal/setitimer.
- * Instead of the two steps of first registering a signal handler to handle
- * \tr{SIGVTALRM} and then start generating them via @setitimer()@, we use
- * the Multimedia API (MM) and its @timeSetEvent@. (Internally, the MM API
- * creates a separate thread that will notify the main thread of timer
- * expiry). -- SOF 7/96
+/* Major bogosity:
+ *
+ * In the threaded RTS, we can't set the virtual timer because the
+ * thread which has the virtual timer might be sitting waiting for a
+ * capability, and the virtual timer only ticks in CPU time.
+ *
+ * So, possible solutions:
+ *
+ * (1) tick in realtime. Not very good, because this ticker is used for
+ * profiling, and this will give us unreliable time profiling
+ * results. Furthermore, this requires picking a single OS thread
+ * to be the timekeeper, which is a bad idea because the thread in
+ * question might just be making a temporary call into Haskell land.
+ *
+ * (2) save/restore the virtual timer around excursions into STG land.
+ * Sounds great, but I tried it and the resolution of the virtual timer
+ * isn't good enough (on Linux) - most of our excursions fall
+ * within the timer's resolution and we never make any progress.
+ *
+ * (3) have a virtual timer in every OS thread. Might be reasonable,
+ * because most of the time there is only ever one of these
+ * threads running, so it approximates a single virtual timer.
+ * But still quite bogus (and I got crashes when I tried this).