|
| 1 | +--- |
| 2 | +layout: wiki |
| 3 | +title: Development |
| 4 | +wiki: development |
| 5 | +--- |
| 6 | + |
| 7 | +### Development |
| 8 | + |
| 9 | +This section contains topics that are under development and have not |
| 10 | +been formalized and added to formal specification or implemented. |
| 11 | + |
| 12 | + |
| 13 | +#### Registry specification |
| 14 | + |
| 15 | +*Problem: current specification doesn't cover the semantics of registry |
| 16 | +if the remote processes can be put into registry and if we can send |
| 17 | +messages to such processes using `nsend`.* |
| 18 | + |
| 19 | +Here is a prosal for semantics that is summary of the [email thread](https://groups.google.com/forum/?hl=en-GB#!topic/cloud-haskell-developers/120_WugguPg) |
| 20 | + |
| 21 | +References are the following: |
| 22 | + |
| 23 | + * Uni - stands for unified semantics for Future Erlang |
| 24 | + |
| 25 | + * Spec - stands for formal CH specification |
| 26 | + |
| 27 | + * ML - stands for mailing list |
| 28 | + |
| 29 | +**Semantics:** |
| 30 | + |
| 31 | + 1. Registry. |
| 32 | + 1. It should be possible to register remote processes in local registry (and local processes in remote registry) |
| 33 | + Rationale: [Uni. Sec 2.3] |
| 34 | + |
| 35 | + 2. If a remote process is stored in registry then Node Controller starts monitoring that process |
| 36 | + Rationale: (Implicit requirement in because node should be able to receive notification about process death) |
| 37 | + |
| 38 | + 3. If a process dies and we get asynchronous notification then we remove process from registry |
| 39 | + Rationale: [Uni. Definition 18, Uni. Table 12] |
| 40 | + |
| 41 | + 2. `nsend` |
| 42 | + |
| 43 | + 1. `nsend` should be implemented in terms of lower level function `whereis` and `send` |
| 44 | + |
| 45 | + 2. `nsend` is process does not exists in registry then message got silently dicarded. |
| 46 | + |
| 47 | + |
| 48 | +Possible problems: |
| 49 | + |
| 50 | +Current proposal opens space for race conditions, we should understand if those are relevant for us, and |
| 51 | +could or could not be solved |
| 52 | + |
| 53 | +a. 2.1 adds a possibility for changing label beetwen where is and send, so message will be |
| 54 | + sent to the wrong process. |
0 commit comments