1. 15 Aug, 2003 1 commit
  2. 12 Jul, 2003 1 commit
  3. 03 Jul, 2003 1 commit
    • sof's avatar
      [project @ 2003-07-03 15:14:56 by sof] · 18340925
      sof authored
      New primop (mingw only),
        asyncDoProc# :: Addr# -> Addr# -> State# RealWorld-> (# State# RealWorld, Int#, Int# #)
      which lets a Haskell thread hand off a pointer to external code (1st arg) for
      asynchronous execution by the RTS worker thread pool. Second arg is data passed
      in to the asynchronous routine. The routine is _not_ permitted to re-enter
      the RTS as part of its execution.
  4. 19 Jun, 2003 1 commit
  5. 14 May, 2003 1 commit
  6. 08 Apr, 2003 1 commit
  7. 02 Apr, 2003 1 commit
  8. 01 Apr, 2003 1 commit
    • sof's avatar
      [project @ 2003-04-01 15:05:13 by sof] · c49a6ca9
      sof authored
      Tidy up code that supports user/Haskell signal handlers.
      Signals.h now defines RTS_USER_SIGNALS when this is supported,
      which is then used elsewhere.
  9. 25 Mar, 2003 2 commits
  10. 19 Mar, 2003 1 commit
  11. 22 Feb, 2003 1 commit
    • sof's avatar
      [project @ 2003-02-22 04:51:50 by sof] · 557947d3
      sof authored
      Clean up code&interfaces that deals with timers and asynchrony:
      - Timer.{c,h} now defines the platform-independent interface
        to the timing services needed by the RTS. Itimer.{c,h} +
        win32/Ticker.{c,h} defines the OS-specific services that
        creates/destroys a timer.
      - For win32 plats, drop the long-standing use of the 'multimedia'
        API timers and implement the ticking service ourselves. Simpler
        and more flexible.
      - Select.c is now solely for platforms that use select() to handle
        non-blocking I/O & thread delays. win32/AwaitEvent.c provides
        the same API on the Win32 side.
      - support threadDelay on win32 platforms via worker threads.
      Not yet compiled up on non-win32 platforms; will do once checked in.
  12. 25 Jan, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-01-25 15:54:48 by wolfgang] · af136096
      wolfgang authored
      This commit fixes many bugs and limitations in the threaded RTS.
      There are still some issues remaining, though.
      The following bugs should have been fixed:
      - [+] "safe" calls could cause crashes
      - [+] yieldToReturningWorker/grabReturnCapability
          -     It used to deadlock.
      - [+] couldn't wake blocked workers
          -     Calls into the RTS could go unanswered for a long time, and
                that includes ordinary callbacks in some circumstances.
      - [+] couldn't block on an MVar and expect to be woken up by a signal
          -     Depending on the exact situation, the RTS shut down or
                blocked forever and ignored the signal.
      - [+] The locking scheme in RtsAPI.c didn't work
      - [+] run_thread label in wrong place (schedule())
      - [+] Deadlock in GHC.Handle
          -     if a signal arrived at the wrong time, an mvar was never
                filled again
      - [+] Signals delivered to the "wrong" thread were ignored or handled
            too late.
      *) If GC can move TSO objects (I don't know - can it?), then ghci
      will occasionally crash when calling foreign functions, because the
      parameters are stored on the TSO stack.
      *) There is still a race condition lurking in the code
      (both threaded and non-threaded RTS are affected):
      If a signal arrives after the check for pending signals in
      schedule(), but before the call to select() in awaitEvent(),
      select() will be called anyway. The signal handler will be
      executed much later than expected.
      *) For Win32, GHC doesn't yet support non-blocking IO, so while a
      thread is waiting for IO, no call-ins can happen. If the RTS is
      blocked in awaitEvent, it uses a polling loop on Win32, so call-ins
      should work (although the polling loop looks ugly).
      *) Deadlock detection is disabled for the threaded rts, because I
      don't know how to do it properly in the presence of foreign call-ins
      from foreign threads.
      This causes the tests conc031, conc033 and conc034 to fail.
      *) "safe" is currently treated as "threadsafe". Implementing "safe" in
      a way that blocks other Haskell threads is more difficult than was
      thought at first. I think it could be done with a few additional lines
      of code, but personally, I'm strongly in favour of abolishing the
      *) Running finalizers at program termination is inefficient - there
      are two OS threads passing messages back and forth for every finalizer
      that is run. Also (just as in the non-threaded case) the finalizers
      are run in parallel to any remaining haskell threads and to any
      foreign call-ins that might still happen.
  13. 13 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-13 15:16:29 by simonmar] · c986ed0b
      simonmar authored
      Shortcut when switching evaluators: instead of going round the normal
      scheduler loop, just cut to the chase and run the thread using the
      other evaluator.
      This avoids doing stack squeezing each time we switch evaluators,
      which is an O(n) operation these days, whereas it used to be O(n) the
      first time, and O(1) thereafter if the stack hadn't changed too much.
      This is a problem that we should perhaps address separately, but for
      now the workaround should provide a speed boost to GHCi on the HEAD.
  14. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
        - Info tables are a bit more complicated.  See InfoTables.h for the
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
  15. 10 Dec, 2002 1 commit
    • wolfgang's avatar
      [project @ 2002-12-10 13:38:40 by wolfgang] · 8a8eee36
      wolfgang authored
      Fix a race condition/possible deadlock in the threaded rts:
      If a callback into haskell finished before waitThread_() was called,
      the signal was lost  ans waitThread_() waited indefinitely.
      Solution: Don't release the sched_mutex between calls to scheduleThread_
      and waitThread_.
      Please note that the scheduler API function waitThread is still possibly
      affected by this race condition. It's used in rts_mainEvalIO (I think that's
      safe) and in finishAllThreads (this looks dangerous, but finishAllThreads is
      never used).
  16. 22 Oct, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-10-22 11:01:18 by simonmar] · b7129526
      simonmar authored
      change the types of cmp_thread, rts_getThreadId, and labelThread to
      take StgPtr rather than StgTSO *, since the compiler now has no
      distinction between these two types in the back end.
      I also noticed that labelThread need not be a primitive: it could just
      as well be a normal C function called by the FFI, but I haven't made
      that change.
  17. 25 Sep, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-09-25 14:46:31 by simonmar] · 28e69a6b
      simonmar authored
      Fix a scheduling/GC bug, spotted by Wolfgang Thaller.  If a main
      thread completes, and a GC runs before the return (from rts_evalIO())
      happens, then the thread might be GC'd before we get a chance to
      extract its return value, leading to barf("main thread has been GC'd")
      from the garbage collector.
      The fix is to treat all main threads which have completed as roots:
      this is logically the right thing to do, because these threads must be
      retained by virtue of holding the return value, and this is a property of
      main threads only.
  18. 18 Sep, 2002 1 commit
  19. 17 Sep, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-09-17 12:20:15 by simonmar] · 4a7c2629
      simonmar authored
      The GC wasn't properly marking pending signal handlers, which could
      lead to "EVACUATED object entered!" errors.  Also, a race occurs if a
      signal arrives during GC.  Two fixes:
        (a) mark all pending signal handlers during GC, and
        (b) block signals during GC
  20. 28 Aug, 2002 1 commit
  21. 16 Aug, 2002 1 commit
  22. 25 Jul, 2002 1 commit
    • sof's avatar
      [project @ 2002-07-25 18:36:59 by sof] · d9d8ab15
      sof authored
      Expose printAllThreads() in non-DEBUG builds;
      of some use when debugging ConcHask code and
      want a dump of the current state of the system's
      Not provided via a library, so to use, do
       foreign import call unsafe printAllThreads :: IO ()
  23. 19 Jul, 2002 2 commits
    • sof's avatar
      [project @ 2002-07-19 18:45:21 by sof] · 0974f1a8
      sof authored
       be less ambitious, and don't kill any main_threads.
       Killing them, and possibly replacing them on the
       main_threads with the current one, turned out to
       run into problems of its own (see comments.)
       The hope/wish is that the current behaviour of
       forkProcess will suffice.
    • sof's avatar
      [project @ 2002-07-19 00:06:05 by sof] · 180e628b
      sof authored
       - fix bug which left run_queue_tl in a bad state.
       - be better behaved wrt 'main threads', i.e.,
         if the killing thread isn't the main thread,
         make sure it's hooked up to main_threads +
         correctly signal the completion/killing of
         any main threads.
  24. 17 Jul, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-07-17 09:21:48 by simonmar] · 7457757f
      simonmar authored
      Remove most #includes of system headers from Stg.h, and instead
      #include any required headers directly in each RTS source file.
      The idea is to (a) reduce namespace pollution from system headers that
      we don't need, (c) be clearer about dependencies on system things in
      the RTS, and (c) improve via-C compilation times (maybe).
      In practice though, HsBase.h #includes everything anyway, so the
      difference from the point of view of .hc source is minimal.  However,
      this makes it easier to move to zero-includes if we wanted to (see
      discussion on the FFI list; I'm still not sure that's possible but
      at least this is a step in the right direction).
  25. 10 Jul, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-07-10 09:28:54 by simonmar] · f477a85c
      simonmar authored
      Fix a GC bug.  In a "large block", only the block descriptor for the
      head of the block has the fields step, gen_no and flags set.  So
      whenever we want one of these fields in the descriptor for a random
      object anywhere in the large block, we have to check whether it is in
      the head block, and if not follow the link to the head block
      evacuate() was doing this correctly, but isAlive() wasn't (and
      goodness knows what other places are broken in this way - I identified
      several other possible cases of the same bug).
      So to try to make things more robust, when we allocate a large block
      we now initialise the step, gen_no, and flags fields in the descriptor
      for *every* sub-block, not just the first one.  Now, as long as you
      only want one of these fields from the descriptor, there's no need to
      try to find the block head.  evacuate() gets minutely faster, and
      hopefully multiple obscure bugs are fixed by this.
  26. 26 Jun, 2002 1 commit
    • stolz's avatar
      [project @ 2002-06-26 08:18:38 by stolz] · fbbed914
      stolz authored
      - Make TSO "stable" again: The thread label was changing the size of the
         TSO if you were building a debugging-RTS, leading to binary
         incompatibility. Now we map TSOs to strings using Hash.c.
      - API change for labelThread: Label arbitrary threads.
  27. 19 Jun, 2002 1 commit
    • sof's avatar
      [project @ 2002-06-19 20:45:14 by sof] · 237ea701
      sof authored
      When handling external call-ins (via the RTS API) in
      the multi-threaded case, add the StgMainThread that
      the external thread is going to block waiting on
      to the main_threads list prior to scheduling the new
      worker thread.
      Do this by having the scheduler provide a new entry
      point, scheduleWaitThread().
      Fixes a bug/race condition spotted by Wolfgang Thaller
      (see scheduleWaitThread() comment) + enables a little
      tidier interface between RtsAPI and Schedule.
  28. 18 May, 2002 1 commit
  29. 11 May, 2002 2 commits
    • sof's avatar
      [project @ 2002-05-11 13:58:18 by sof] · 263ebdd8
      sof authored
      Have createThread() use a separate mutex to ensure unique
      allocation of ThreadIds. A less-than-light solution, but
      cleaner than trying to reuse sched_mutex for this purpose.
    • sof's avatar
      [project @ 2002-05-11 00:16:11 by sof] · 32a27624
      sof authored
      As a result of calling exitScheduler(), enter into a
      'shutting-down' state, so that the subsequent (sequential)
      execution of finalisers won't get stuck inside the
      Scheduler waiting for more work.
      Cleanest way I could think of solving this problem on a
      Friday afternoon.
  30. 26 Apr, 2002 1 commit
    • sof's avatar
      [project @ 2002-04-26 22:35:54 by sof] · 6a268d86
      sof authored
      When the OS thread is all out of work, shut down in a gentler
      manner by calling shutdownHaskell() rather than
      shutdownHaskellAndExit(). Give up the sched_mutex lock also.
  31. 23 Apr, 2002 3 commits
    • sof's avatar
      [project @ 2002-04-23 14:20:18 by sof] · 95c57852
      sof authored
      forkProcess() mingw unused arg tweak
    • stolz's avatar
      [project @ 2002-04-23 09:56:28 by stolz] · 85126d52
      stolz authored
      - set thread labels to NULL after free()
      - labelThread# didn't exit properly
      TODO: Labels are prematurely free()d when a thread terminates. Better let
              the GC worry?
    • sof's avatar
      [project @ 2002-04-23 06:34:26 by sof] · 30a97b4c
      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
      * 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
      * There's still a ^C-related problem which causes the Haskell
        handler to sometimes induce a SEGV when run. Feel free to debug :)
  32. 13 Apr, 2002 1 commit
    • sof's avatar
      [project @ 2002-04-13 05:33:02 by sof] · 6a00c0fd
      sof authored
      - clarified/fixed sched_mutex locking problems when
        calling raiseAsync() from withing the bowels of the Scheduler.
      - we now yieldToReturningWorker() as part of the main Scheduler
      - simplified grabCapability() and waitForWorkCapability() usage.
  33. 10 Apr, 2002 1 commit
    • stolz's avatar
      [project @ 2002-04-10 11:43:43 by stolz] · c1f3fad1
      stolz authored
      Two new scheduler-API primops:
      1) GHC.Conc.forkProcess/forkProcess# :: IO Int
         This is a low-level call to fork() to replace Posix.forkProcess().
         In a Concurrent Haskell setting, only the thread invoking forkProcess()
         is alive in the child process. Other threads will be GC'ed!
            This brings the RTS closer to pthreads, where a call to fork()
         doesn't clone any pthreads, either.
            The result is 0 for the child and the child's pid for the parent.
         The primop will barf() when used on mingw32, sorry.
      2) GHC.Conc.labelThread/forkProcess# :: String -> IO ()
         Useful for scheduler debugging: If the RTS is compiled with DEBUGging
         support, this primitive assigns a name to the current thread which
         will be used in debugging output (+RTS -D1). For larger applications,
         simply numbering threads is not sufficient.
           Notice: The Haskell side of this call is always available, but if
         you are not compiling with debugging support, the actual primop will
         turn into a no-op.
  34. 01 Apr, 2002 1 commit
  35. 12 Mar, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-03-12 13:57:11 by simonmar] · 5eedab2c
      simonmar authored
      If we are in a deadlock situation but there are signal handlers
      installed, pause() instead of reporting deadlock.  One of the signal
      handlers may allow the process to continue after being triggered.
      Fixes bug #525772.
      I've made a half-hearted attempt to clean up the deadlock code in the
      scheduler, it now looks slightly better.