|Version 6 (modified by john@…, 8 years ago) (diff)|
on the wiki:
- The Control.Concurrency module
Papers and other docs:
- Concurrent Haskell (the original paper, including a semantics)
- Extending the Haskell FFI with Concurrency (a specification of the interaction between concurrency and the FFI, with a semantics)
- A Draft report addendum (a shorter version of the above paper).
- Software Transactional Memory
- Vital for some modern applications and large applications commonly require it.
- Stable MVar implementation is well understood and tested.
- Imposes non trivial implementation constraints.
- Providing a 'select' and non-blocking IO would be enough to allow people to implement something like it themselves in haskell and are provided by most systems as primitives.
- Things like the 'poor man's concurrency monad' can achieve some of the benefits
- Standardise on Concurrent Haskell without STM. It is our view that even in the presence of STM, MVars offer functionality that is distinct from STM and separately useful, so this leaves room for growth.
- Use the semantics from Extending the Haskell FFI with Concurrency
- Decide how much pre-emption is acceptable, and figure out how to specify this.
- Should we specify what an implementation that doesn't provide concurrency should do? (e.g. provide an implementation of MVars in terms of IORefs, so that concurrency-safe libraries can be written portably).
- Require bound thread support, or make it optional? (YHC has concurrency with non-blocking foreign calls, but doesn't have bound threads as yet.)
There are several levels of concurrency support which require sucessivly more implementation support and imply more implementation overhead.
The report says nothing about concurrency at all
Enough is specified to allow people to write completley portable programs and libraries that while they may not depend on concurrency, will not break in the presence of it.
This would entail
- A standardized MVar-like structure.
- something along the lines of ForeignBlocking
This would allow concurrency needing programs to be written, but perhaps not as transparently as it curently is with GHC. This would include everything needed to write concurrent programs without anything that would imply a run-time or implementation overhead in the non-concurrent case.