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

Vlad Dumitrescu vladdu55@REDACTED
Mon May 5 13:29:35 CEST 2014

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.

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.

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

More information about the erlang-questions mailing list