CP013: Make modifications based on feedback.

* Add minor corrections.
* Add requirement for execution_resource iterators to be random access.
* Add section to background discussing handle partial errors on topology
discovery.

Author: Gordon

affinity/cpp-20/d0796r3.md

@@ -165,7 +165,13 @@ From a historic perspective, programming models for traditional high-performance
 
 Some of these programming models also address *fault tolerance*. In particular, PVM has native support for this, providing a mechanism [[27]][pvm-callback] which can notify a program when a resource is added or removed from a system. MPI lacks a native *fault tolerance* mechanism, but there have been efforts to implement fault tolerance on top of MPI [[28]][mpi-post-failure-recovery] or by extensions[[29]][mpi-fault-tolerance].
 
-Due to the complexity involved in standardizing *dynamic resource discovery* and *fault tolerance*, these are currently out of the scope of this paper. However, we leave open the possibility of accommodating both in the future, by not overconstraining *resources*' lifetimes (see next section).
+Due to the complexity involved in standardizing *dynamic resource discovery* and *fault tolerance*, these are currently out of the scope of this paper. However, we leave open the possibility of accommodating both in the future, by not over constraining *resources*' lifetimes (see next section).
+
+### Reporting errors in topology discovery
+
+As querying the topology of a system can invoke a number of different system and third-party library, we have to consider what will happen when a call to one of these fails. Firstly we want to be able to report this failure so that it can be reported or handled in user code. Secondly as there will often be more than one source of topology discovery we have to avoid short-circuiting the discovery on an error and preventing potentially valid topology information being reported to users. For example if a system were to report both Hwloc and OpenCL execution resources and one of these failed we want the other to still be able to return it's resources.
+
+A potential solution to this could be support partial errors in topology discovery, where querying the system for it's topology could be permitted to fail but still return a valid topology structure representing the topology that was discovered successfully. The way in which these errors are reported (i.e. exceptions or error values) would have to be decided, exceptions could be problematic as it could unwind the stack before capturing important topology information so perhaps an error value based approach would be preferable.
 
 ### Resource lifetime
 
@@ -286,7 +292,7 @@ An `execution_resource` object can be queried for a pointer to it's parent `exec
 
 An `execution_resource` object can also be queried for the amount concurrency it can provide, the total number of **threads of execution** supported by the associated **execution resource**.
 
-> [*Note:* An **execution resource** is not limited to resources which execute work, but also a general resource where no execution can take place but memory can be allocated such as off-chip memory. *--end note*]
+> [*Note:* An **execution resource** is not limited to resources which execute work, but also a general resource where no execution can take place but memory can be allocated, such as off-chip memory. *--end note*]
 
 Below *(Listing 3)* is an example of iterating over every **execution resource** within the **system topology** and printing out their capabilities.
 
@@ -343,7 +349,7 @@ auto &execResource = execContext.resource();
 
 // systemResource[0] should be equal to execResource
 
-for (const execution::execution_resource res : execResource()) {
+for (const execution::execution_resource &res : execResource) {
     std::cout << res.name()  << "\n";
 }
 ```
@@ -393,10 +399,11 @@ The `execution_resource` which underlies the current thread of execution can be
     class execution_resource {
      public:
 
+      using value_type = execution_resource;
       using pointer = execution_resource *;
       using const_pointer = const execution_resource *;
-      using iterator = execution_resource *;
-      using const_iterator = const execution_resource *;
+      using iterator = see-below;
+      using const_iterator = see-below;
       using reference = execution_resource &;
       using const_reference = const execution_resource &;
       using size_type = std::size_t;
@@ -413,7 +420,7 @@ The `execution_resource` which underlies the current thread of execution can be
       const_iterator begin() const noexcept;
       const_iterator end() const noexcept;
 
-      const_reference operator[](int child) const noexcept;
+      const_reference operator[](std::size_t child) const noexcept;
 
       const_pointer member_of() const noexcept;
 
@@ -522,6 +529,18 @@ The `execution_resource` class provides an abstraction over a system's hardware,
 
 > [*Note:* Creating an `execution_resource` may require initializing the  underlying software abstraction when the `execution_resource` is constructed, in order to discover other `execution_resource`s accessible through it. However, an `execution_resource` is nonowning. *--end note*]
 
+### `execution_resource` member types
+
+    iterator
+
+*Requires:* `iterator` to model `RandomAccessIterator` with the value type `execution_resource::value_type`.
+
+    const_iterator
+
+*Requires:* `const_iterator` to model `RandomAccessIterator` with the value type `execution_resource::value_type`.
+
+iterator_traits<>iterator_category
+
 ### `execution_resource` constructors
 
     execution_resource() = delete;
@@ -551,13 +570,13 @@ The `execution_resource` class provides an abstraction over a system's hardware,
 
     const_iterator begin() const noexcept;
 
-*Returns:* A const iterator to the beggining of the child `execution_resource`s.
+*Returns:* A const iterator to the beginning of the child `execution_resource`s.
 
     const_iterator end() const noexcept;
 
 *Returns:* A const iterator to the end of the child `execution_resource`s.
 
-    const_reference operator[](int child) const noexcept;
+    const_reference operator[](std::size_t child) const noexcept;
 
 *Returns:* A const reference to the specified child `execution_resource`s.
 
@@ -581,7 +600,7 @@ The `execution_resource` class provides an abstraction over a system's hardware,
 
 The `execution_context` class provides an abstraction for managing a number of lightweight execution agents executing work on an `execution_resource` and any `execution_resource`s encapsulated by it. The `execution_resource` which an `execution_context` encapsulates is referred to as the *contained resource*.
 
-### `execution_context` types
+### `execution_context` member types
 
     using executor_type = see-below;