[erlang-questions] The implementation of link/1 and monitor/2

[Nahuel Greco]

1. No, links are managed natively by the scheduler/virtual machine, check
beam/erl_monitors.h, they are NOT process. Think about them as "lines"
connecting process.

2. No, same as (1).

3. They are true language primitives. I think the only way to re-implement
them is to create some sort of supervisor process and poll using
erlang:process_info/2 to check if the process is alive. But that will be a
CPU waste.

4. I think yes but you will need a third process to manage the "link"
between two process, to call exit(pid,kill) on the "linked" process not
defined to trap exits, and must implement process_flag(trap_exit, true),
spawn_link et al. Monitors were added later to the language, there is
probably some sort of more fundamental structure to be factored out of
monitors and links.


Saludos,
Nahuel Greco.

On Fri, Sep 12, 2014 at 10:22 AM, Torbjörn Lager <torbjorn.lager@REDACTED>
wrote:

> Hi there,
>
> I have read about links and monitors in Erlang and think I'm beginning to
> understand how they work. I'm a bit curious how they are implemented
> though.
>
> 1. It seems to me that for a link between two processes P1 and P2, two
> OTHER processes are needed, one watching over P1 and one watching over P2.
> Is this how Erlang implements links?
>
> 2. It seems to me that a monitor is also a kind of process. Is it a
> regular Erlang process of the kind you can spawn yourself?
>
> 3. Related: If Erlang didn't have link/1 and monitor/2 as BIFs, could they
> be implemented in Erlang, or are they true language primitives?
>
> 4. Related: If Erlang had only monitor/2, could link/1 somehow be
> implemented in terms of it?
>
> Thanks,
> Torbjörn
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140915/9ddf0db5/attachment.htm>