[erlang-questions] Visual Erlang notation v0.1.0 - feedback request

Torben Hoffmann torben.hoffmann@REDACTED
Mon May 5 20:53:29 CEST 2014

Vlad Dumitrescu writes:

> On Mon, May 5, 2014 at 1:18 PM, Torben Hoffmann <
> torben.hoffmann@REDACTED> wrote:
>> Vlad Dumitrescu writes:
>> > Just a thought that connects with the patterns discussion: linking to
>> > another process is usually permanent, that is we don't unlink from it.
>> > Process monitoring can be more dynamic. In any case, it is possible to
>> have
>> > links/monitors that are dynamic and thus runtime properties. IMHO, one
>> > might want to handle these differently than the static ones. On the other
>> > hand, this might be an anti-pattern?
>> >
>> Ai, ai, ai!
>> Dynamic linking/monitoring is far from trivial.
>> The idiomatic danger of unlinking is that you can end up with processes
>> that are no
>> longer associated with the supervision tree of your application.
>> In most cases you would probably have some naïve link in the supervision
>> tree and
>> then add linking/monitoring from a different place in the tree to the
>> processes you
>> are interested in.
>> Do you have a good example of where you use dynamic linking/monitoring
>> that we could
>> base the discussion on?
>> I'd hate to provide notation for anti-patterns, but if we are missing
>> something on
>> the dynamic front then now is a good time to get it in.
> No, I don't have a full example at the moment. Of course, when using
> linking with supervision trees, then the linking should be static, i.e. for
> the lifetime of the process. I have in the past used linking outside
> supervision, but nowadays I would have used monitors instead.
I tend to agree with you - links for the static structure of the supervision tree and
then monitoring for the more dynamic things.

If others have examples where dynamic linking makes sense, please speak up.

> As a simplified example, let's take a tree of processes where parents
> monitor their children and the children their parents. When moving a child
> to another parent, the monitors will change.
> It might not be something that is used often in systems, but since it is a
> possibility, I think that the architecture description should have a way to
> describe it. Or it should be decided that such monitors have nothing to do
> in the architecture diagrams, which is perfectly acceptable IMHO.
Monitors should definitely be part of the notation.

See this manager-worker pattern:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Erlang-Patterns-P7.png
Type: image/png
Size: 53755 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140505/732060a3/attachment.png>
-------------- next part --------------

This is a static monitoring set-up, which is needed to solve this particular problem.

The P process spawns a manager process which spawns the worker processes.
Should one of the workers die the manager exits and process P, which is monitoring
the manager, gets a down message due to it monitoring the manager.

Right now I cannot come up with a good example where dynamic monitoring makes sense,
so I would like to hear if others have one.


> regards,
> Vlad

Torben Hoffmann
Erlang Solutions Ltd.
Tel: +45 25 14 05 38

More information about the erlang-questions mailing list