1. 11 Dec, 2017 1 commit
  2. 29 Apr, 2017 1 commit
  3. 12 Feb, 2017 2 commits
    • Niklas Hambüchen's avatar
      bufWrite: Save extra syscall when data fills handle buffer completely. · 6b4e46a1
      Niklas Hambüchen authored
      The bug is that the check `if (size - w > count)` should be
      `if (size - w >= count)` instead (`>=` instead of `>`),
      because we can do the write all fine if it fits exactly.
      This allows us to do 1 instead of 2 write syscalls the case it fits.
      
      An example of when this matters is when an application writes output
      in chunks that are a fraction of the handle buffer size.
      
      For example, assume the buffer size is 8 KB, and the application writes
      four 2 KB chunks.
      Until now, this would result in 3 copies to the handle buffer, but
      the 4th one would not be allowed in by `size - w > count`
      (because `size - w == count` is the case), so we'd end up with a write
      syscall of only 6 KB data instead of 8 KB, thus creating more syscalls
      overall.
      
      Implementing this fix (switching to `size - w >= count`), we also have
      to flush the buffer if we fill it completely.
      
      If we made only the changes described so far, that would have the
      unintended side effect that writes of the size equal to the handle
      buffer size (`count == size`) suddenly also go to the handle buffer
      first: The data would first be copied to the handle buffer, and then
      immediately get flushed to the underlying FD.  We don't want that extra
      `memcpy`, because it'd be unnecessary: The point of handle buffering is
      to coalesce smaller writes, and there are no smaller writes in this
      case.  For example, if you specify 8 KB buffers (which menas you want
      your data to be written out in 8 KB blocks), and you get data that's
      already 8 KB in size, you can write that out as an 8 KB straight away,
      zero-copy fashion.  For this reason, adding to the handle buffer now got
      an additional condition `count < size`.  That way, writes equal to the
      buffer size go straight to the FD, as they did before this commit.
      
      Reviewers: simonmar, austin, hvr, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3117
      6b4e46a1
    • Niklas Hambüchen's avatar
      Fix: hPutBuf issues unnecessary empty write syscalls for large writes (#13246) · 805db965
      Niklas Hambüchen authored
      Until now, any `hPutBuf` that wrote `>= the handle buffer size` would
      trigger an unnecessary `write("")` system call before the actual write
      system call.
      
      This is fixed by making sure that we never flush an empty handle buffer:
      Only flush `when (w > 0)`.
      
      Reviewers: simonmar, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3119
      805db965
  4. 11 Mar, 2016 1 commit
  5. 23 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Allow CallStacks to be frozen · 380b25ea
      Eric Seidel authored
      This introduces "freezing," an operation which prevents further
      locations from being appended to a CallStack.  Library authors may want
      to prevent CallStacks from exposing implementation details, as a matter
      of hygiene. For example, in
      
      ```
      head [] = error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      including the call-site of `error` in `head` is not strictly necessary
      as the error message already specifies clearly where the error came
      from.
      
      So we add a function `freezeCallStack` that wraps an existing CallStack,
      preventing further call-sites from being pushed onto it. In other words,
      
      ```
      pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
      ```
      
      Now we can define `head` to not produce a CallStack at all
      
      ```
      head [] =
        let ?callStack = freezeCallStack emptyCallStack
        in error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      ---
      
      1. We add the `freezeCallStack` and `emptyCallStack` and update the
         definition of `CallStack` to support this functionality.
      
      2. We add `errorWithoutStackTrace`, a variant of `error` that does not
         produce a stack trace, using this feature. I think this is a sensible
         wrapper function to provide in case users want it.
      
      3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
         rationale is that base does not export any functions that use CallStacks
         (except for `error` and `undefined`) so there's no way for the stack
         traces (from Implicit CallStacks) to include user-defined functions.
         They'll only contain the call to `error` itself. As base already has a
         good habit of providing useful error messages that name the triggering
         function, the stack trace really just adds noise to the error. (I don't
         have a strong opinion on whether we should include this third commit,
         but the change was very mechanical so I thought I'd include it anyway in
         case there's interest)
      
      4. Updates tests in `array` and `stm` submodules
      
      Test Plan: ./validate, new test is T11049
      
      Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1628
      
      GHC Trac Issues: #11049
      380b25ea
  6. 16 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Start using `-W` instead of `-f(no-)warn` in some places · 437ebdda
      Herbert Valerio Riedel authored
      This replaces some occurences of `-f(no-)warn` with the new `-W`-aliases
      introduced via 2206fa8c / #11218, in cases which are guaranteed
      to be invoked with recent enough GHC (i.e. the stage1+ GHC).
      
      After this commit, mostly the compiler and the testsuite remain using
      `-f(wo-)warn...` because the compiler needs to be bootstrappable with
      older GHCs, while for the testsuite it's convenient to be able to quickly
      compare the behavior to older GHCs (which may not support the new flags yet).
      
      The compiler-part can be updated to use the new flags once GHC 8.3 development
      starts.
      
      Reviewed By: quchen
      
      Differential Revision: https://phabricator.haskell.org/D1637
      437ebdda
  7. 30 Oct, 2014 1 commit
    • David Feuer's avatar
      Fix #9236 Error on read from closed handle · 257cbec2
      David Feuer authored
      Summary:
      Fixes #9236. My testing indicates that this does *not* lead to problems with
      broken pipes and such, but further testing is required. It found
      a bug in haddock; I've submitted a pull request upstream.
      
      Reviewers: ekmett, austin
      
      Reviewed By: ekmett, austin
      
      Subscribers: rwbarton, thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D327
      
      GHC Trac Issues: #9236
      257cbec2
  8. 24 Sep, 2014 1 commit
  9. 18 Sep, 2014 1 commit
  10. 28 Sep, 2013 1 commit
  11. 22 Sep, 2013 1 commit
  12. 15 Jun, 2013 1 commit
  13. 24 Mar, 2013 1 commit
  14. 27 Mar, 2012 1 commit
  15. 18 Nov, 2011 1 commit
  16. 26 Oct, 2011 1 commit
  17. 13 Oct, 2011 1 commit
  18. 11 Oct, 2011 1 commit
  19. 18 Jun, 2011 1 commit
  20. 18 May, 2011 1 commit
    • batterseapower's avatar
      Use Unicode private-use characters for roundtripping · d3ebf520
      batterseapower authored
      This replaces the previous scheme (which used lone surrogates). The reason is that
      there is Haskell software in the wild (i.e. the text package) that chokes on Char values
      that do not represent Unicode characters.
      
      This new approach will not work correctly if the reserved private-use characters are
      actually encountered in the input, but we expect this to be rare.
      d3ebf520
  21. 28 Jan, 2011 1 commit
  22. 21 Jan, 2011 1 commit
  23. 18 Dec, 2010 1 commit
  24. 25 Nov, 2010 1 commit
    • Simon Marlow's avatar
      Encode immediately in hPutStr and hPutChar · 62c11c91
      Simon Marlow authored
      This means that decoding errors will be detected accurately, and can
      be caught and handled.  Overall the implementation is simpler this way
      too.
      
      It does impose a performance hit on small hPutStrs, although larger
      hPutStrs seem to be unaffected.  To compensate somewhat, I optimised
      hPutStrLn.
      62c11c91
  25. 24 Nov, 2010 1 commit
  26. 16 Nov, 2010 1 commit
  27. 27 Oct, 2010 1 commit
  28. 16 Sep, 2010 1 commit
  29. 09 Sep, 2010 1 commit
  30. 29 Jun, 2010 1 commit
  31. 24 Jun, 2010 1 commit
  32. 15 Jun, 2010 1 commit
  33. 17 May, 2010 1 commit
  34. 05 May, 2010 1 commit
  35. 04 May, 2010 1 commit
  36. 25 Mar, 2010 1 commit
  37. 25 Nov, 2009 1 commit
  38. 12 Oct, 2009 1 commit
    • Simon Marlow's avatar
      Make hGetContents throw an exception if an error is encountered · 23c183b0
      Simon Marlow authored
      Strictly speaking this breaks Haskell 98 compatibility, which requires
      hGetContents to just end the lazy stream silently if an error is
      encountered.  However, for a few reasons we think it will make
      everyone's life a bit easier if we make this change
      
       1. Errors will be a lot more common in GHC 6.12.1, in the form
          of Unicode decoding errors.
      
       2. When Haskell 98 was designed, we didn't know how to throw
          exceptions from inside lazy I/O, but now we do.
      
       3. If anyone is actually relying on the previous behaviour, their
          code is arguably broken.
      23c183b0
  39. 27 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Fix hWaitForInput · bc41c09e
      Simon Marlow authored
      It was erroneously waiting when there were bytes to decode waiting in
      the byte buffer.
      bc41c09e