Expose ability to set up bi-directional links

Hey Tim!

That's for the awesome answer! I did not expect that much detailed version

I am slowly getting close to finalizing of implementation of the language itself (some odd pattern matchings are what's left to actually implement), and now I am going to focus on BIFs, including most of process related (trap_exit is a tough one...) and most of IO subsystem. Later I'll try to figure out how to implement inter-node distribution. I am doing it by trying to run OTP's init.erl and actually make shell work.

If d-p is best place for it, feel free to move this feature request to d-p-platform.

Feel free to post this to a mailing list. And please let me know which one is that, so I can join as well. Defining semantics can be tough, I'll think about it after studying CH semantics document. Ideally we'd want something close enough to Erlang's semantics, but consistency with other parts of CH seems to be more important.

Another solution would be to open up some of internals of CH, so I, on my own risk, can hack something workable, without expecting anything from you in terms of API stability.

Cheers,
Gleb

P.S. It's awesome to see new CH release on Hackage! Good job!

Hi @Gleb Peregud - sorry for the delay in looking at this. The semantics on which cloud haskell is based - Unified Semantics for Future Erlang (see http://haskell-distributed.github.io/static/semantics.pdf for our reading of that paper) - explicitly avoided bi-directional linking, arguing that this is better achieved by monitoring alone. On that basis, I'm not particularly keen on implementing it, since to do so properly, you'd need to actually provide some semantics for both the distributed and local (intra-node) case. The problem with the existing Erlang bif is that the semantics are effectively defined by the implementation.

If we introduce bi-directional linking, we must not only deal with the case where one side of the link dies before the other - the obvious race - but also we must somehow think about lifting the concept of linking differently since in Cloud Haskell, unlike Erlang links cause termination regardless of the reason why the linked-to peer process dies. In fact, we introduced the linkOnFailure primitive as an extension in distributed-process-platform to provide a link-esque primitive that works more like Erlangs. See https://github.com/haskell-distributed/distributed-process-platform/blob/master/src/Control/Distributed/Process/Platform/Internal/Primitives.hs#L160 for the code. You'll notice that the implementation is not nice and neat - this is as much a kludge as the solution you're proposing for bi-directional links.

Both these features have their place, but are not covered by the formal semantics. The reason for leaving them out (of the semantics) is that the Unified Semantics paper argues that we're better off without them. I've been willing to add things such as these as afterthoughts in d-p-platform since people asked for them, but I have so far remained unwilling to alter the code in distributed-process - specifically, the node controller implementation which governs much of the runtime operation and provides an implementation of all our semantic guarantees.

Does this mean I'm unwilling to consider adding bi-directional linking to Cloud Haskell? No, but I would like to hear a good argument against the proposition made in the Unified Semantics paper (the original one, not our semantics overview) that makes the case for it. I'd also like to see that argument go through some bike-shedding on the cloud-haskell-developers and parallel-haskell mailing lists, so that others have the opportunity to share in the discussion. If the consensus is that we should add these features (or change cloud haskell's semantics to use bi-directional instead of uni-directional linking) then we'll do that.

Now of course, your reason for asking about this is a bit of a special case: an Erlang interpreter running on Cloud Haskell is going to be a tough ask if we cannot (or will not) provide the full set of BIFs and `link' is pretty much bread and butter. There will be a lot of Erlang programs that cannot run without it, or worse, will have undefined (application) semantics if we don't provide a bi-directional version. So I can see why we'd want this, but I can tell you now, it's not going to be easy to implement it. Firstly, we have to fully define the semantics - the fact that CH has formal semantics is one of our big selling points - and then we'll have to figure out how to provide those within whatever framework of guarantees we can make. The alternative would be to just hack something together using a middleman process and monitors, as I've done for `linkOnFailure', which is a kludge but works, though it provides no guarantees whatsoever in terms of CH semantics.

Phew, sorry that was such an essay. Does what I'm saying sound reasonable and shall we proceed with discussing this on the mailing lists? If you think so, please link to this issue too, so everyone involved can read up on the background and so we can make them aware of your work!