1. 03 Dec, 2021 1 commit
  2. 18 Nov, 2021 1 commit
  3. 01 Apr, 2021 1 commit
  4. 14 Feb, 2021 1 commit
  5. 24 Sep, 2020 1 commit
  6. 05 Aug, 2020 1 commit
  7. 31 Jan, 2020 1 commit
  8. 15 Mar, 2019 1 commit
  9. 02 Mar, 2018 1 commit
  10. 23 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Allow CallStacks to be frozen · 380b25ea
      Eric Seidel authored and Ben Gamari's avatar Ben Gamari committed
      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
      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
  11. 24 Oct, 2015 1 commit
  12. 23 Oct, 2015 1 commit
  13. 01 Jun, 2015 1 commit
    • Ben Gamari's avatar
      Fix dropped event registrations · 1c383259
      Ben Gamari authored
      D347 introduced a bug wherein the event manager would drop registrations that
      should be retained during processing. This occurs when an fd has multiple
      registrations, not all of which fire, as well as the case of multi-shot
      I also do some general house-keeping, try to better document things, and fix a
      bug which could result in unnecessary calls to `epoll_ctl`
      Reviewed By: austin
      Differential Revision: https://phabricator.haskell.org/D849
      GHC Trac Issues: #10317
  14. 02 Feb, 2015 1 commit
    • AndreasVoellmy's avatar
      Fix #10017 · 92c93544
      AndreasVoellmy authored
      In the threaded RTS, a signal is delivered from the RTS to Haskell
      user code by writing to file that one of the IO managers watches (via
      an instance of GHC.Event.Control.Control). When the IO manager
      receives the signal, it calls GHC.Conc.Signal.runHandlers to invoke
      Haskell signal handler. In the move from a single IO manager to one IO
      manager per capability, the behavior was (wrongly) extended so that a
      signal is delivered to every event manager (see #9423), each of which
      invoke Haskell signal handlers, leading to multiple invocations of
      Haskell signal handlers for a single signal. This change fixes this
      problem by having the RTS (in generic_handler()) notify only the
      Control instance used by the TimerManager, rather than all the
      per-capability IO managers.
      Reviewers: austin, hvr, simonmar, Mikolaj
      Reviewed By: simonmar, Mikolaj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D641
  15. 12 Jan, 2015 1 commit
    • Ben Gamari's avatar
      Event Manager: Make one-shot a per-registration property · 02343998
      Ben Gamari authored
      Currently the event manager has a global flag for whether to create
      epoll-like notifications as one-shot (e.g. EPOLLONESHOT, where an fd
      will be deactivated after its first event) or standard multi-shot
      Unfortunately this means that the event manager may export either
      one-shot or multi-shot semantics to the user. Even worse, the user has
      no way of knowing which semantics are being delivered. This resulted in
      breakage in the usb[1] library which deadlocks after notifications on
      its fd are disabled after the first event is delivered.  This patch
      reworks one-shot event support to allow the user to choose whether
      one-shot or multi-shot semantics are desired on a per-registration
      basis. The event manager can then decide whether to use a one-shot or
      multi-shot epoll.
      A registration is now defined by a set of Events (as before) as well as
      a Lifetime (either one-shot or multi-shot). We lend monoidal structure
      to Lifetime choosing OneShot as the identity. This allows us to combine
      Lifetime/Event pairs of an fd to give the longest desired lifetime of
      the registration and the full set of Events for which we want
      [1] https://github.com/basvandijk/usb/issues/7
      Test Plan: Add more test cases and validate
      Reviewers: tibbe, AndreasVoellmy, hvr, austin
      Reviewed By: austin
      Subscribers: thomie, carter, simonmar
      Differential Revision: https://phabricator.haskell.org/D347
  16. 02 Nov, 2014 1 commit
  17. 21 Sep, 2014 1 commit
  18. 18 Sep, 2014 2 commits
  19. 16 Sep, 2014 2 commits
    • Herbert Valerio Riedel's avatar
      Move `Maybe`-typedef into GHC.Base · b4752199
      Herbert Valerio Riedel authored
      This is preparatory work for reintroducing SPECIALISEs that were lost
      in d94de872
      Differential Revision: https://phabricator.haskell.org/D214
    • AndreasVoellmy's avatar
      Revert "Revert "rts/base: Fix #9423"" and resolve issue that caused the revert. · 7e658bc1
      AndreasVoellmy authored
      This reverts commit 4748f593. The fix for #9423
      was reverted because this commit introduced a C function setIOManagerControlFd()
      (defined in Schedule.c) defined for all OS types, while the prototype
      (in includes/rts/IOManager.h) was only included when mingw32_HOST_OS is
      not defined. This broke Windows builds.
      This commit reverts the original commit and resolves the problem by only defining
      setIOManagerControlFd() when mingw32_HOST_OS is defined. Hence the missing prototype
      error should not occur on Windows.
      In addition, since the io_manager_control_wr_fd field of the Capability struct is only
      usd by the setIOManagerControlFd, this commit includes the io_manager_control_wr_fd
      field in the Capability struct only when mingw32_HOST_OS is not defined.
      Test Plan: Try to compile successfully on all platforms.
      Reviewers: austin
      Reviewed By: austin
      Subscribers: simonmar, ezyang, carter
      Differential Revision: https://phabricator.haskell.org/D174
  20. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      Test Plan: Build things, they might not explode horribly.
      Reviewers: hvr, simonmar
      Subscribers: simonmar
      Differential Revision: https://phabricator.haskell.org/D13
  21. 22 Aug, 2014 1 commit
  22. 19 Aug, 2014 1 commit
    • AndreasVoellmy's avatar
      rts/base: Fix #9423 · f9f89b78
      AndreasVoellmy authored
      Fix #9423.
      The problem in #9423 is caused when code invoked by `hs_exit()` waits
      on all foreign calls to return, but some IO managers are in `safe` foreign
      calls and do not return. The previous design signaled to the timer manager
      (via its control pipe) that it should "die" and when the timer manager
      returned to Haskell-land, the Haskell code in timer manager then signalled
      to the IO manager threads that they should return from foreign calls and
      `die`. Unfortunately, in the shutdown sequence the timer manager is unable
      to return to Haskell-land fast enough and so the code that signals to the
      IO manager threads (via their control pipes) is never executed and the IO
      manager threads remain out in the foreign calls.
      This patch solves this problem by having the RTS signal to all the IO
      manager threads (via their control pipes; and in addition to signalling
      to the timer manager thread) that they should shutdown (in `ioManagerDie()`
      in `rts/Signals.c`. To do this, we arrange for each IO manager thread to
      register its control pipe with the RTS (in `GHC.Thread.startIOManagerThread`).
      In addition, `GHC.Thread.startTimerManagerThread` registers its control pipe.
      These are registered via C functions `setTimerManagerControlFd` (in
      `rts/Signals.c`) and `setIOManagerControlFd` (in `rts/Capability.c`). The IO
      manager control pipe file descriptors are stored in a new field of the
      `Capability_ struct`.
      Test Plan: See the notes on #9423 to recreate the problem and to verify that it no longer occurs with the fix.
      Auditors: simonmar
      Reviewers: simonmar, edsko, ezyang, austin
      Reviewed By: austin
      Subscribers: phaskell, simonmar, ezyang, carter, relrod
      Differential Revision: https://phabricator.haskell.org/D129
      GHC Trac Issues: #9423, #9284
  23. 19 Apr, 2014 1 commit
  24. 12 Oct, 2013 1 commit
  25. 08 Sep, 2013 1 commit
  26. 03 Sep, 2013 1 commit
    • bos's avatar
      Switch IO manager to a mutable hashtable · 28cf2e00
      bos authored and AndreasVoellmy's avatar AndreasVoellmy committed
      This data structure (IntTable) provides a similar API to its predecessor
      (IntMap), at half the number of lines in size.
      When tested in isolation using criterion, IntTable is much faster than
      IntMap: over 15x, according to my criterion benchmarks.
      This translates into a measurable improvement when used in the IO manager:
      using weighttp to benchmark acme-http under various configurations on two
      32-core Linux servers connected by a 10gbE network, I see between a 3%
      and 10% increase in requests served per second compared to IntMap.
      Signed-off-by: AndreasVoellmy's avatarAndreas Voellmy <andreas.voellmy@gmail.com>
  27. 08 Jun, 2013 1 commit
  28. 06 May, 2013 1 commit
    • AndreasVoellmy's avatar
      Update parallel IO manager to handle the invalid files in the same way as previous IO manager. · c5a4de9d
      AndreasVoellmy authored
      This patch affects the IO manager using kqueue. See issue #7773. If the kqueue backend cannot wait for events on a file, it will simply call the registered callback for the file immediately. This is the behavior of the previous IO manager. This is not ideal, but it is an initial step toward dealing with the problem properly. Ideally, we would use a non-kqueue mechanism for waiting on files (select seems most reliable) that cannot be waited on with kqueue.
  29. 12 Feb, 2013 10 commits