[erlang-questions] Fishing for best practices: distributed twin processes!

[Michael Truog]

Just to be clear, the remote VM dieing helps initiate the death of the links or monitors, since the node is shown as down locally.  You can catch that condition separately with node monitoring.

On 09/14/2012 06:55 PM, Michael Truog wrote:
> Yes, you will get a message from a monitor or link to a process on a remote node, which requires that the nodes be connected, when the remote process dies.  You can just have premature death if the net tick time is too long (not sure why, but it seemed like some internal assumption that is made, not controlled by the net tick time, saw in an older release but I assume it is the same still), so that is why it is best to stick with the default net tick time, unless you want to test that mechanism alot.
>
> On 09/14/2012 06:46 PM, Roberto Ostinelli wrote:
>> hello Michael,
>>
>> you're assuming right (separate VM), I'm familiar with links and monitors, thank you. However I doubt that any message is sent from a dying process if the VM on which it runs actually blows up. That was my point.
>>
>> r.
>>
>>
>> On Fri, Sep 14, 2012 at 3:47 PM, Michael Truog <mjtruog@REDACTED <mailto:mjtruog@REDACTED>> wrote:
>>
>>     Assuming you have the 2 layers in separate Erlang VMs.  You can have the Erlang VMs connected with distributed Erlang, and have the twin processes monitoring each other.  If you wanted a simple process death if either died, you could consider using a link instead of 2 monitors.  However, that seems like the simplest solution, to avoid unnecessary complexity.  You might find strangeness if you start not using the default net tick time (i.e., with a process link inbetween nodes), with distributed Erlang, but you probably know it is best to not play with that.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120914/dbeaad1b/attachment.htm>