| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
They are not part of the IOManager interface used within the rest of the
RTS. They are the part of the interface of specific I/O manager
implementations.
They are no longer called directly elsewhere in the RTS, and are now
only called by the dispatch functions in IOManager.c
|
| |
|
|
|
|
|
| |
Use in the scheduler in threaded mode.
Replaces the direct call to ioManagerWakeup which are part of specific
I/O manager implementations.
|
| |
|
|
|
|
|
|
|
|
| |
Replace a direct call to ioManagerStartCap in the forkProcess in
Schedule.c with a new hook initIOManagerAfterFork in IOManager.
This replaces a direct hook in the scheduler from the a single I/O
manager impl (the threaded unix one) with a generic hook.
Add some commentrary on opportunities for future rationalisation.
|
| | |
|
| |
|
|
|
| |
This is a better home for it. It is not really an aspect of
capabilities. It is specific to one of the I/O manager impls.
|
|
|
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 patch makes a start by creating a new IOManager.{h,c} module. It is
initially empty, but we will move things into it in subsequent patches.
|
