Skip to content

Start to centralise the I/O manager hooks

Duncan Coutts requested to merge dcoutts/ghc:dcoutts/io-manager-api into master

It is currently rather difficult to understand or work with the various I/O manager implementations. This is for a few reasons:

  1. They do not have a clear or common API. There are some common function names, but a lot of things just get called directly.
  2. They have hooks into many other parts of the RTS where they get called from.
  3. There is a lot of CPP involved, both THREADED_RTS vs !THREADED_RTS and also mingw32_HOST_OS vs !mingw32_HOST_OS. This doesn't really identify the I/O manager implementation.
  4. They have data structures with unclear ownership, or that are co-owned with other components like the scheduler. Some data structures are used by multiple I/O managers.

One thing that would help is if the interface between the I/O managers and the rest of the RTS was clearer, even if it was not completely uniform. Centralising it would make it easier to see how to reduce any unnecessary diversity in the interfaces.

This MR makes a start by

  • creating a new IOManager.h/IOManager.c module with hooks for I/O manager startup, shutdown, wakeup.

The next steps should be

  • introducing a per-cap I/O manager structure
  • moving the {blocked,sleeping}_queue from being scheduler global vars to the per-cap I/O manager structure
  • clarify the tests used in the scheduler for whether I/O or timers are pending
  • see whether the two calls to awaitEvent in the scheduler can be reduced to one
  • try to make the tests for pending I/O & timers make sense for the WinIO case
  • move the select() and win32 MIO I/O managers to use MVars/IOPorts for blocking, rather than using custom blocking states
  • adjust the CPP so it more clearly identifies I/O manager implementations, rather than platform characteristics
  • further clarify the interface to the I/O managers and as much as possible make it the same for them all, or just two major kinds: scheduler-integrated or Haskell-side.

Note that MR !4691 (closed) also goes in this direction, but it makes much more sense for this MR to go first and that one to be rebased on top.

Edited by Duncan Coutts

Merge request reports