jyapayne/Nim
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

minor changes to the threading docs

Browse source
This commit is contained in:
Araq 2014-11-01 01:14:51 +01:00
commit dac43e0fdd
2 changed files with 12 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

13
doc/manual/threads.txt
View file

@ -74,8 +74,8 @@ Threads and exceptions
---------------------- ----------------------
The interaction between threads and exceptions is simple: A *handled* exception The interaction between threads and exceptions is simple: A *handled* exception
in one thread cannot affect any other thread. However, an *unhandled* in one thread cannot affect any other thread. However, an *unhandled* exception
exception in one thread terminates the whole *process*! in one thread terminates the whole *process*!
@ -94,9 +94,10 @@ module to work.
Somewhat confusingly, ``spawn`` is also used in the ``parallel`` statement Somewhat confusingly, ``spawn`` is also used in the ``parallel`` statement
with slightly different semantics. ``spawn`` always takes a call expression of 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`` 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 then ``spawn``'s return type is also ``void`` otherwise it is ``FlowVar[T]``.
``spawn``'s return type is ``T``, 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 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 read prematurely within a ``parallel`` section and so there is no need for
the overhead of an indirection via ``FlowVar[T]`` to ensure correctness. 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. is performed via ``system.deepCopy`` and so can be overriden.
* For *safe* data exchange between ``f`` and the caller a global ``TChannel`` * 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 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 ``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 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`` 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 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.

9
todo.txt
View file

@ -1,8 +1,9 @@
version 0.10 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 version 0.9.6
============= =============
@ -49,8 +50,8 @@ Bugs
version 0.9.x version 0.9.x
============= =============
- implicit deref for parameter matching; but only for x.f(a, b) --> looks like
- implicit deref for parameter matching a nice compromise
- overloading of '=' - overloading of '='
- allow simple read accesses to global variables --> difficult to ensure that - allow simple read accesses to global variables --> difficult to ensure that
no data races happen no data races happen