diff options
| author | Araq <rumpf_a@web.de> | 2014-11-01 01:14:51 +0100 |
|---|---|---|
| committer | Araq <rumpf_a@web.de> | 2014-11-01 01:14:51 +0100 |
| commit | dac43e0fdd393c3267040e91e95592ba184a4527 (patch) | |
| tree | 7ca5bbec5c0ae79bde8b93448db0ee1dc5fe0c42 | |
| parent | 2e26734ea72253f219064e6d9a6e0fd89b5f049e (diff) | |
| download | Nim-dac43e0fdd393c3267040e91e95592ba184a4527.tar.gz | |
minor changes to the threading docs
| -rw-r--r-- | doc/manual/threads.txt | 13 | ||||
| -rw-r--r-- | todo.txt | 9 |
2 files changed, 12 insertions, 10 deletions
diff --git a/doc/manual/threads.txt b/doc/manual/threads.txt index a96abf060..245545f6f 100644 --- a/doc/manual/threads.txt +++ b/doc/manual/threads.txt @@ -74,8 +74,8 @@ Threads and exceptions ---------------------- The interaction between threads and exceptions is simple: A *handled* exception -in one thread cannot affect any other thread. However, an *unhandled* -exception in one thread terminates the whole *process*! +in one thread cannot affect any other thread. However, an *unhandled* exception +in one thread terminates the whole *process*! @@ -94,9 +94,10 @@ module to work. Somewhat confusingly, ``spawn`` is also used in the ``parallel`` statement with slightly different semantics. ``spawn`` always takes a call expression of the form ``f(a, ...)``. Let ``T`` be ``f``'s return type. If ``T`` is ``void`` -then ``spawn``'s return type is also ``void``. Within a ``parallel`` section -``spawn``'s return type is ``T``, otherwise it is ``FlowVar[T]``. +then ``spawn``'s return type is also ``void`` otherwise it is ``FlowVar[T]``. +Within a ``parallel`` section sometimes the ``FlowVar[T]`` is eliminated +to ``T``. This happens when ``T`` does not contain any GC'ed memory. The compiler can ensure the location in ``location = spawn f(...)`` is not read prematurely within a ``parallel`` section and so there is no need for the overhead of an indirection via ``FlowVar[T]`` to ensure correctness. @@ -133,7 +134,7 @@ that ``spawn`` takes is restricted: is performed via ``system.deepCopy`` and so can be overriden. * For *safe* data exchange between ``f`` and the caller a global ``TChannel`` needs to be used. However, since spawn can return a result, often no further - communication is required. + communication is required. ``spawn`` executes the passed expression on the thread pool and returns @@ -158,7 +159,7 @@ Data flow variables ensure that no data races are possible. Due to technical limitations not every type ``T`` is possible in a data flow variable: ``T`` has to be of the type ``ref``, ``string``, ``seq`` or of a type that doesn't contain a type that is garbage collected. This -restriction will be removed in the future. +restriction is not hard to work-around in practice. diff --git a/todo.txt b/todo.txt index 3e511dc49..417c2ef04 100644 --- a/todo.txt +++ b/todo.txt @@ -1,8 +1,9 @@ version 0.10 ============ -- Test nimfix on various babel packages - +- Declare nimfix as beta-quality. +- make nimble part of the distribution +- fix babelpackagelist bug version 0.9.6 ============= @@ -49,8 +50,8 @@ Bugs version 0.9.x ============= - -- implicit deref for parameter matching +- implicit deref for parameter matching; but only for x.f(a, b) --> looks like + a nice compromise - overloading of '=' - allow simple read accesses to global variables --> difficult to ensure that no data races happen |