1. 25 Jul, 2010 1 commit
  2. 01 Aug, 2010 4 commits
  3. 31 Jul, 2010 1 commit
  4. 30 Jul, 2010 1 commit
    • Ian Lynagh's avatar
      Always haddock by default · 8ca53757
      Ian Lynagh authored
      Revert this patch:
          Matthias Kilian <kili@outback.escape.de>**20090920181319
          Don't build haddock if HADDOC_DOCS = NO, and disable HADDOC_DOCS
              if GhcWithInterpreter = NO
          Haddock uses TcRnDriver.tcRnGetInfo, which is only available if
          GHCI is built. Set HADDOC_DOCS to NO if GhcWithInterpreter is NO,
          and disable the haddock build if HADDOC_DOCS = NO.
      8ca53757
  5. 29 Jul, 2010 1 commit
  6. 30 Jul, 2010 1 commit
  7. 20 Jul, 2010 1 commit
    • pgj's avatar
      Add thread affinity support for FreeBSD · 13346da2
      pgj authored
      - Implement missing functions for setting thread affinity and getting real
        number of processors.
      - It is available starting from 7.1-RELEASE, which includes a native support
        for managing CPU sets.
      - Add __BSD_VISIBLE, since it is required for certain types to be visible in
        addition to POSIX & C99. 
      13346da2
  8. 29 Jul, 2010 1 commit
    • Ian Lynagh's avatar
      Disable symbol visibility pragmas for FreeBSD · 28c2bbb0
      Ian Lynagh authored
      Do not use GCC pragmas for controlling visibility, because it causes
      "undefined reference" errors at link-time.  The true reasons are
      unknown, however FreeBSD 8.x includes GCC 4.2.1 in the base system,
      which might be buggy. 
      28c2bbb0
  9. 21 Jul, 2010 1 commit
  10. 28 Jul, 2010 2 commits
  11. 27 Jul, 2010 1 commit
  12. 26 Jul, 2010 2 commits
  13. 25 Jul, 2010 1 commit
  14. 24 Jul, 2010 5 commits
  15. 23 Jul, 2010 4 commits
  16. 21 Jul, 2010 1 commit
  17. 19 Jul, 2010 1 commit
  18. 22 Jul, 2010 1 commit
  19. 21 Jul, 2010 4 commits
  20. 20 Jul, 2010 4 commits
  21. 16 Jul, 2010 1 commit
    • Simon Marlow's avatar
      Use a separate mutex to protect all_tasks, avoiding a lock-order-reversal · ed301949
      Simon Marlow authored
      In GHC 6.12.x I found a rare deadlock caused by this
      lock-order-reversal:
      
      AQ cap->lock
        startWorkerTask
          newTask
            AQ sched_mutex
      
      scheduleCheckBlackHoles
        AQ sched_mutex
         unblockOne_
          wakeupThreadOnCapabilty
            AQ cap->lock
      
      so sched_mutex and cap->lock are taken in a different order in two
      places.
      
      This doesn't happen in the HEAD because we don't have
      scheduleCheckBlackHoles, but I thought it would be prudent to make
      this less likely to happen in the future by using a different mutex in
      newTask.  We can clearly see that the all_tasks mutex cannot be
      involved in a deadlock, becasue we never call anything else while
      holding it.
      ed301949
  22. 15 Jul, 2010 1 commit