| … | … | @@ -142,13 +142,13 @@ Changes since January 2025: |
| 142 | 142 | the core AtomSpace. |
| 143 | 143 | |
| 144 | 144 | There is one missing feature, but no one uses it (yet): support for |
| 145 | | multiple atomspaces (aka frames) is missing. Work on adding this was |
| 145 | multiple AtomSpaces (aka frames) is missing. Work on adding this was |
| 146 | 146 | started but is low priority. One unit test works. See the `cog-simple` |
| 147 | 147 | directory. |
| 148 | 148 | |
| 149 | 149 | Build |
| 150 | 150 | ----- |
| 151 | | Prerequistes: of course the AtomSpace is needed: |
| 151 | Prerequisites: of course the AtomSpace is needed: |
| 152 | 152 | https://github.com/opencog/atomspace but so is the base `StorageNode` |
| 153 | 153 | API, at https://github.com/opencog/atomspace-storage |
| 154 | 154 | |
| … | … | @@ -191,7 +191,7 @@ asynchronously. In other words, requests might be handled out-of-order. |
| 191 | 191 | If there is some critical code segment that can't tolerate this, use the |
| 192 | 192 | `(barrier)` call. It will flush the network buffers, and force a |
| 193 | 193 | serialization barrier at the remote end. The `(barrier)` is a 'fence' |
| 194 | | and not a synchronization chekpoint: it ensures that all reads/writes |
| 194 | and not a synchronization checkpoint: it ensures that all reads/writes |
| 195 | 195 | before the barrier are completed before any that come after are started. |
| 196 | 196 | |
| 197 | 197 | Usage is much like before: |