| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add JS backend adapted from the GHCJS project by Luite Stegeman.
Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.
Bump array submodule
Work funded by IOG.
Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>
|
| |
|
|
|
|
|
| |
This was an unfortunate oversight in the original event manager rework
patch. Fixes #10308
Differential Revision: https://phabricator.haskell.org/D845
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
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
notifications.
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
notification.
[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
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This commit removes a couple of
{-# OPTIONS_GHC -fno-warn-unused-imports #-}
by cleaning up the imports, as well as ensuring that all modules in the
GHC.* hierarchy avoid importing the `Prelude` module to clean-up the
import graph a bit.
|
| |
|
|
|
|
|
|
| |
This just addresses the specific issue raised in #9165. However, I've noticed
the Haddock comments need to be improved, which will be addressed by a separate
commit.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
| |
registration once it has received a callback.
Previously, GHC.Event.Thread.threadWait calls unregister on the file in the callback. With this flag on, the manager now performs the deregistration so that GHC.Event.Thread.threadWait does not have to. The motivation for the change is that for the common case that we deregister after receiving the callback, we can provide a more efficient implementation which reduces the number of times the callback table lock is taken in half and also reduces the number of sysystem calls we make to the backend. This commit does not implement that optimization; it just paves the way for this change in future.
|
| |
|
|
| |
The timer related features have been moved to TimerManager.
|
| |
|
|
| |
This is a preliminary patch; ultimately the single file IO manager will be replaced by per-capability managers.
|
| |
|
|
|
|
| |
io manager changes.
These functions are considered GHC-private and are not used by any packages on hackage.
|
| |
|
|
| |
A search of hackage showed that all packages that use this module (which is considered private to GHC) do not use the 'new' function.
|
| | |
|
| | |
|
| | |
|
|
|
It's just an internal GHC library, for now at least
|
