Registry

[qnikst]

An PR for an early review that implement registry according to unified semantics.

The main attention should be paid to d305553 where linking was introduced.

[hyperthunk]

Some initial comments..

Why do we link instead of monitor here? Don't both allow us to remove dead remote pids?

Also I think we should decompose ncEffectRegister further. It's getting quite hard to follow the logic and I think breaking the function up into smaller functions (in the where... section) with explanatory variable names would make it much more readable.

[qnikst]

Why do we link instead of monitor here? Don't both allow us to remove dead remote pids?

Really first question here do we need such kind of monitoring at all. The key thoughts are the following:
a. if anybody monitors process then event about process death will be received by node and node controller will clean registry
b. if nobody monitors process then event about process death will never be received that this is potential leak
c. we want only event about process death and not want to distinguish between how it died.

So my solution was: use the lightest possible mechanism to subscribe to event death, so I chosen linking. Maybe we need another approach or do not introduce additional monitoring at all, but then it should be documented in both specification and haddocks.

Also I think we should decompose ncEffectRegister further. It's getting quite hard to follow the logic and I think breaking the function up into smaller functions (in the where... section) with explanatory variable names would make it much more readable.

I agree. Also I think that I need to make separate PR for this commit and debate it there.

[hyperthunk]

So my solution was: use the lightest possible mechanism to subscribe to event death

Yeah fair enough, as long as receiving the link notification does what we want. I don't really understand how linking works when there's no receiver though - won't this just blow up in the NC event loop when we see the link failure signal from the remote node? I should probably re-read that code shouldn't I.... :/

I agree. Also I think that I need to make separate PR for this commit and debate it there.

That's a really good point. Please open an issue so we don't forget! Thanks.

[qnikst]

I've just run tests and current monitoring implementation doesn't work as needed. So my plan is the following:

1. split out this patch into separate branch
2. introduce tests for new semantics
3. resubmit this PR without last patch
4. send email to cloud-haskell-developers with questions about the best way to proceed with monitoring

Also I have created a bug report: https://cloud-haskell.atlassian.net/browse/DP-100

[qnikst]

1,2,3 (haskell-distributed/distributed-process-tests#11) done

All tests are passing.

[facundominguez]

This text needs to be edited. I offer a version below. However a few things are amiss.

• Nothing is said about ordering of messages sent with nsend and nsendRemote
• Nothing is said about how the registry behaves on failures.
• The subsection is included in Open Issues, but I don't see any issue remarked as open.

It is apparent now that the semantics need to include register, unregister and possibly nsendRemote as primitives.

---

The identifiers of both local and remote processes can be stored in the Registry. The operation \texttt{registerRemoteAsync} can register processes at remote nodes. When a message is sent to a remote node using \texttt{nsendRemote} there is no guarantee that the process that should receive the message is located at the node; thus it may be necessary to relay the message to a process on yet another node.

Both operations nsend and nsendRemote discard the messages if no process is registered with the given name.

[facundominguez]

I think I understand now the open issue. This PR fixes nsend for remote processes but not nsendRemote.

If it is not too complicated, I'd rather prefer to see a PR that fixes both functions rather than augmenting the Open Issues section of the semantic notes.

[qnikst]

Thanks for fixing semantics document, I'll use that text and will cover all questions you've raised. nsendRemote is not hard to fix, I really missed that function, so will do as soon as I'll be able.

OpenIssues is a bug opened on jira (https://cloud-haskell.atlassian.net/browse/DP-100) about semantics for value removal, see cloud-haskell-developers@ for full explanation. I think I'll remove it from semantics and leave only the umspecified section for the things that were not specified in semantics.

[qnikst]

I have updated PR, now it contains implementation for nsendRemote and fixes to semantics mentioned by @facundominguez.

[qnikst]

This PR is outdated due to #184