Link and Monitor reflection to Runtime

[vertexclique]

Stale copy from rkallos's comment on lobste.rs:

This looks pretty cool! I definitely see the resemblance to Erlang’s model of lightweight processes. That said, I couldn’t find the primitives upon which Erlang’s supervisors are built; links and monitors.

The idea of uni- or bi-directional links between processes seems to be more flexible and powerful than representing supervisor trees directly in code. Two examples come to mind:

1. Process A waiting for a response from process B, but process B crashed after receiving the message from A. This could be solved by having process A create a uni-directional link (‘monitor’ in Erlang) to B before sending the message.

2. Process A is responsible for maintaining state about a set of other processes managed by one or more supervisors. With links in Erlang, this is easy, and with trap_exit, process A can see how these processes exit, and update its state accordingly.

With supervision trees, you gain the ability to manage how some groups of processes are managed. With links and monitors, you gain the building blocks on which Erlang’s supervision trees are built, and much more.

[vertexclique]

Link concept in Erlang:

• https://erlangbyexample.org/links
• http://erlang.org/doc/reference_manual/processes.html#links

Monitor concept in Erlang:

• https://erlangbyexample.org/monitors
• http://erlang.org/doc/reference_manual/processes.html#monitors

This issue partially relates to (from most to least): #116 #118 #119

[Relrin]

This could be such a nice feature for bastion!

Does bastion have any support for tracking states of each declared supervisor or an actor (useful methods, fields in structs)? Especially the most required thing to have here is to have a method for getting a formatted state (minimal as much as possible) for any instance.

[vertexclique]

State API recently entered in #149 . @onsails is working on the mailbox preservation across restarts. That will enable link implementation for individual level. After that we can have link method to watch supervision of selected items.

For monitor we need a little bit more upwork, monitor means one more backchannel from the spawned child to spawner so receiving endpoint (which is spawner) will see the crash scenarios. Might come handy if we have a drop on closures when closure is dropped in poller (msg! is our message poller). we notify the monitor (if monitor exist if not, no need to notify anyone).

[vertexclique]

One more thing I just realized, we create one more type in lightproc level. Currenlty RecoverableHandle and ProcHandle is existing. Like the name says RecoverableHandle is recovering from panics. We can have a MonitorHandle that will hand out a channel receiver inside the handle to talk through. Needs exploration, that will be a nice idea to do plenty of recovery scenarios. (For both bi- and uni- directional cases.)

https://docs.rs/lightproc/0.3.3/lightproc/recoverable_handle/struct.RecoverableHandle.html