1. 20 Aug, 2009 2 commits
  2. 19 Aug, 2009 5 commits
  3. 20 Aug, 2009 1 commit
  4. 19 Aug, 2009 5 commits
  5. 18 Aug, 2009 1 commit
  6. 19 Aug, 2009 3 commits
  7. 18 Aug, 2009 2 commits
    • Thomas Schilling's avatar
      Remove the lock around NameCache for readBinIface. · cadba810
      Thomas Schilling authored
      Turns out using atomic update instead of a full-blown lock was easier
      than I thought.  It should also be safe in the case where we
      concurrently read the same interface file.  Whichever thread loses the
      race will simply find that all of the names are already defined and
      will have no effect on the name cache.
    • Simon Marlow's avatar
      Fix #3429: a tricky race condition · c5cafbcc
      Simon Marlow authored
      There were two bugs, and had it not been for the first one we would
      not have noticed the second one, so this is quite fortunate.
      The first bug is in stg_unblockAsyncExceptionszh_ret, when we found a
      pending exception to raise, but don't end up raising it, there was a
      missing adjustment to the stack pointer.  
      The second bug was that this case was actually happening at all: it
      ought to be incredibly rare, because the pending exception thread
      would have to be killed between us finding it and attempting to raise
      the exception.  This made me suspicious.  It turned out that there was
      a race condition on the tso->flags field; multiple threads were
      updating this bitmask field non-atomically (one of the bits is the
      dirty-bit for the generational GC).  The fix is to move the dirty bit
      into its own field of the TSO, making the TSO one word larger (sadly).
  8. 17 Aug, 2009 3 commits
  9. 06 Aug, 2009 2 commits
  10. 18 Aug, 2009 1 commit
  11. 17 Aug, 2009 2 commits
    • Thomas Schilling's avatar
      Make the dynamic linker thread-safe. · 4fa44a3a
      Thomas Schilling authored
      The current implementation is rather pessimistic.  The persistent
      linker state is now an MVar and all exported Linker functions are
      wrapped in modifyMVar calls.  This is serves as a big lock around all
      linker functions.
      There might be a chance for more concurrency in a few places. E.g.,
      extending the closure environment and loading packages might be
      independent in some cases.  But for now it's better to be on the safe
    • Thomas Schilling's avatar
      Make access to NameCache atomic. Sometimes needs a lock. · 9f68c348
      Thomas Schilling authored
      'readBinIface' updates the name cache in a way that is hard to use
      with atomicModifyIORef, so this patch introduces a lock for this case.
      All other updates use atomicModifyIORef.
      Having a single lock is quite pessimistic, so it remains to be seen
      whether this will become a problem.  In principle we only need to make
      sure that we do not load the same file concurrently (or that it's
      idempotent).  In practice we also need to ensure that concurrent reads
      do not cancel each other out (since the new NameCache may be based on
      an outdated version).
  12. 16 Aug, 2009 2 commits
  13. 22 Jul, 2009 1 commit
  14. 16 Aug, 2009 2 commits
  15. 14 Aug, 2009 3 commits
  16. 13 Aug, 2009 2 commits
    • Ian Lynagh's avatar
      Only look up whether a module's SOURCE-imported if it's in the current package · 0e3d5132
      Ian Lynagh authored
      Suppose we import anotherPackage:M, which exports things from
      anotherPackage:Internal. Then GHC will want to read
      However, if we have also SOURCE-imported thisPackage:Internal then
      we don't want GHC to try to read anotherPackage:Internal.hi-boot
      The mapping that tells us whether a module is SOURCE-imported uses just
      the module name for the key, so we have to check the package ID before
      looking it up.
      Fixes #3007.
    • simonpj@microsoft.com's avatar
      Fix Trac #3409: type synonyms that discard their arguments · 2d1262b6
      simonpj@microsoft.com authored
      Type synonyms that don't mention one of their type parameters on the 
      RHS are a pain in the neck.  This patch fixes a long-standing bug (that
      simply has not appeared before) in that exprType could return a type
      mentioning an existentially-quantified variable (in one of those ignored
      argument positions).
      See CoreUtils Note [Existential variables and silly type synonyms]
      The fix is not entirely beautiful, but it works, and is very localised.
  17. 12 Aug, 2009 2 commits
  18. 11 Aug, 2009 1 commit