CSY/reowolf Changeset - b17fad1f8c03 · Centrum Wiskunde & Informatica (CWI)

Changeset - b17fad1f8c03

Parent rev.

Child rev.

[Not reviewed]

feat-examples

0 2 0

MH - 3 years ago 2022-05-19 22:52:30
contact@maxhenger.nl

Small addition to documentation regarding removal of primitve/composite nomenclature

2 files changed with 8 insertions and 0 deletions:

docs/runtime/01_runtime.md

docs/runtime/04_known_issues.md

0 comments (0 inline, 0 general)

docs/runtime/01_runtime.md

➞

Show inline comments

 This is the trick we will apply in the consensus algorithm. If a channel did not see any messages passing through it, then the components that own those ports will not have to reach consensus because they will not be part of the same synchronous region. However if a message did go through the channel then the components join the same synchronous region, and they'll have to form some sort of consensus on what interaction took place on that channel.
 And so the `put`ting component will only submit its own `(component ID, port ID, metadata_for_sync_round)` triplet. The `get`ting port will submit information containing `(self component ID, self port ID, peer component ID, peer port ID, metadata_for_sync_round)`. The consensus algorithm can now figure out which two ports belong to the same channel.
 ## Component Nomenclature
 Earlier versions of the Reowolf runtime featured the distinction between primitive and composite components. This was put into the language from a design perspective. Primitive components could do nitty-gritty protocol execution: perform `put`/`get` operations, and entering into sync blocks. Conversely, composite components were tasked with setting up a network of interconnected components: creating channels and handing off the appropriate ports to the instantiated components.
 Once the runtime was capable of sending ports over channels, it became apparent that this distinction no longer made sense. Because if only primitive components can send/receive ports, and cannot create new components, then the programmer is limited to using those received ports directly in the primitive's code! And so the split between primitive and composite components was removed: only the concept of a "component" is left.
@@ \ No newline at end of file @@

docs/runtime/04_known_issues.md

➞

Show inline comments

 - The TCP listener component should probably do a `shutdown` before a `close` on the socket handle. It should also set the `SO_REUSEADDR` option.
 - The TCP listener and TCP sender components have not been tested extensively in a multi-threaded setup.
 - The way in which putting ports are ordered to block if the corresponding getter port's main inbox is full is rather silly. This led to the introduction of the "backup inbox" as it is found in the runtime's code. There is a design decision to make here, but the current implementation is a bit silly. There are two options: (a) have an atomic boolean indicating if the message slot for an inbox is full, or (b) do away with the "main inbox" alltogether, and have an unbounded message queue.
 - For practical use in components whose code supports an arbitrary number of peers (i.e. their code contains an array of ports that is used for communication and changes in size during the component's lifetime), the `select` statement somehow needs to support waiting on any one of those ports.

0 comments (0 inline, 0 general)