Event Manager: Make one-shot a per-registration property
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 (cherry picked from commit 02343998)
Showing
- libraries/base/GHC/Event.hs 0 additions, 1 deletionlibraries/base/GHC/Event.hs
- libraries/base/GHC/Event/IntTable.hs 4 additions, 0 deletionslibraries/base/GHC/Event/IntTable.hs
- libraries/base/GHC/Event/Internal.hs 48 additions, 0 deletionslibraries/base/GHC/Event/Internal.hs
- libraries/base/GHC/Event/Manager.hs 120 additions, 104 deletionslibraries/base/GHC/Event/Manager.hs
- libraries/base/GHC/Event/Thread.hs 3 additions, 3 deletionslibraries/base/GHC/Event/Thread.hs
Loading
Please register or sign in to comment