Skip to content

Changes

Page history
add proposals + rationale from the discussion (more to come) authored by simonmar@microsoft.com's avatar simonmar@microsoft.com
Hide whitespace changes
Inline Side-by-side
concurrency.md
View page @ 5ad2d7eb
# Concurrency
## References
## Proposals
These are proposals on which we are generally agreed so far, with
brief rationale.
- Some kind of concurrency will be included in the spec, including `MVar`s for communication.
At least the following interface will be provided:
- [ Control.Concurrent.MVar](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html) - everything except `addMVarFinalizer`
- [ Control.Concurrent](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html) - `ThreadId`, `myThreadId`, `forkIO`, `yield`, `sleep` (replaces `threadDelay`).
- `Control.Concurrent.Chan`, `Control.Concurrent.QSem`,
`Control.Concurrent.QSemN`, `Control.Concurrent.SampleVar`
- Concurrent foreign calls are required.
**Rationale**:
on the wiki:
- concurrent foreign calls are required to guarantee progress of other Haskell threads when one thread makes a blocking call.
- concurrent foreign calls are required for implementing I/O multiplexing, a principle use of concurrency.
- concurrent foreign calls are required to guarantee timely responsiveness of an interactive application in the presence of long-running foreign calls.
- [ForeignBlocking](foreign-blocking)
- Concurrent/reentrant foreign calls are required. Hence, the
Haskell system must be able to process call-ins from arbitrary
external OS threads.
**Rationale**:
- the main loop of a GUI may block (hence concurrent) and makes callbacks (hence reentrant), we need to support this kind of usage.
- providing concurrent/reentrant foreign calls does not impose significant extra overhead on the rest of the system. For example, a call-in can check a thread-local variable (fast) to see whether it arose from a foreign call.
- Foreign calls will be able to specify independently whether they
are concurrent, reentrant, or both. (syntax and the sense of the annotations are still to be decided, see below).
**Rationale**:
- these annotations can have a profound impact on performance in some implementations.
- Bound threads are not required, but allowed as an extension, and we
will specify their meaning.
---
## References
Documentation:
......@@ -23,21 +58,11 @@ Papers and other docs:
---
# Proposal
## what is required by the standard
At least the following interface will be provided
- [ Control.Concurrent.MVar](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html) - everything except `addMVarFinalizer`
- [ Control.Concurrent](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html) - `ThreadId`, `myThreadId`, `forkIO`, `yield`, `sleep` (replaces `threadDelay`).
- `Control.Concurrent.Chan`, `Control.Concurrent.QSem`, `Control.Concurrent.QSemN`,
`Control.Concurrent.SampleVar`
# Old Stuff
the FFI must be able to handle 'concurrent nonrentrant' imports, but not
necessarily 'concurrent reentrant' ones.
What follows is old material, which we will probably want to
incorporate into the main text later.
## Progress Guarentee
......