Clean-up (#598)

oneapi-src · Oct 1, 2021 · 144f75f · 144f75f
1 parent b3d63b7
commit 144f75f
Show file tree

Hide file tree

Showing 4 changed files with 4 additions and 8 deletions.
diff --git a/doc/main/tbb_userguide/Data_Flow_Graph.rst b/doc/main/tbb_userguide/Data_Flow_Graph.rst
@@ -191,8 +191,7 @@ This final implementation has all of the nodes and edges from the
 much advantage in using an ``input_node`` over an explicit loop. But,
 because an ``input_node`` is able to react to the behavior of downstream
 nodes, it can limit memory use in more complex graphs. For more
-information, see `Creating a Token-Based
-System <create_token_based_system.html#create_token_based_system>`__
+information, see:ref:`create_token_based_system` .
 
 
 .. |image0| image:: Images/flow_graph.jpg

diff --git a/doc/main/tbb_userguide/destroy_graphs_outside_main_thread.rst b/doc/main/tbb_userguide/destroy_graphs_outside_main_thread.rst
@@ -9,8 +9,7 @@ You may not always want to block the main application thread by calling
 wait_for_all(). However, it is safest to call wait_for_all on a graph
 before destroying it. A common solution is to enqueue a task to build
 and wait for the graph to complete. For example, assume you really do
-not want to call a wait_for_all in the example from `Always Use
-wait_for_all() <always_use_wait_for_all.html#always_use_wait4all>`__,
+not want to call a wait_for_all in the example from :ref:`always_use_wait_for_all`,
 Instead you can enqueue a task that creates the graph and waits for it:
 
 

diff --git a/doc/main/tbb_userguide/use_graph_reset.rst b/doc/main/tbb_userguide/use_graph_reset.rst
@@ -7,8 +7,7 @@ Use graph::reset() to Reset a Canceled Graph
 When a graph execution is canceled either because of an unhandled
 exception or because its task_group_context is canceled explicitly, the
 graph and its nodes may be left in an indeterminate state. For example,
-in the code samples shown in `Cancel a Graph
-Explicitly <cancel_a_graph.html#cancel_a_graph>`__ the input 2 may be
+in the code samples shown in :ref:`cancel_a_graph` the input 2 may be
 left in a buffer. But even beyond remnants in the buffers, there are
 other optimizations performed during the execution of a flow graph that
 can leave its nodes and edges in an indeterminate state. If you want to

diff --git a/doc/main/tbb_userguide/use_input_node.rst b/doc/main/tbb_userguide/use_input_node.rst
@@ -29,8 +29,7 @@ All ``input_node`` objects are constructed in the inactive state and usually
 activated after the entire flow graph is constructed.
 
 
-For example, you can use the code in `Data Flow
-Graph <Data_Flow_Graph.html#Data_Flow_Graph>`__. In that implementation,
+For example, you can use the code in :ref:`Data_Flow_Graph`. In that implementation,
 the ``input_node`` is constructed in the inactive state and activated after
 all other edges are made: