[erlang-questions] Unidirectional linking?

Igor Ribeiro Sucupira <>
Wed May 25 09:13:55 CEST 2011


The Parent might call this right before calling unlink:

spawn(fun() -> erlang:monitor(Parent), erlang:monitor(Child), receive
{'DOWN', _, _, _, _} -> erlang:exit(Child, timeout) end end),

This way, if Parent dies right after calling unlink, the monitor
process will kill Child and then exit.

If the Parent succeeds in unlinking and then killing Child, the
monitor will be notified of the death of Child and will also finish.

Not perfect, not beautiful, but maybe it is enough.

Thanks.
Igor.

On Wed, May 25, 2011 at 3:39 AM, Igor Ribeiro Sucupira <> wrote:
> I was thinking about something like that right now, trying to convince
> myself that it could work with a third process. :)  Thanks! I will try
> it.
>
> Best regards.
> Igor.
>
> --
> "The secret of joy in work is contained in one word - excellence. To
> know how to do something well is to enjoy it." - Pearl S. Buck.
>
>
> On Wed, May 25, 2011 at 3:34 AM, Joseph Wayne Norton
> <> wrote:
>>
>> Igor -
>>
>> I suggest to add a simple proxy process (or add this functionality to the
>> parent process if it is better suited) that has a receive clause for the
>> operation's response, the operation's monitor exit, and an after clause with
>> the operation's timeout.  If timeout occurs, you can demonitor and kill the
>> operation's process.
>>
>> - Joe N
>>
>> On Wed, 25 May 2011 15:24:23 +0900, Igor Ribeiro Sucupira <>
>> wrote:
>>
>>> I couldn't see a way of using monitors in this example. I would need
>>> the child process to monitor its parent, but the child is busy
>>> performing Op.
>>>
>>> Thanks.
>>> Igor.
>>>
>>> On Wed, May 25, 2011 at 3:16 AM, Bengt Kleberg
>>> <> wrote:
>>>>
>>>> Greetings,
>>>>
>>>> Uni-directional links are created with erlang:monitor/2.
>>>>
>>>> Does this help?
>>>>
>>>>
>>>> bengt
>>>>
>>>> On Wed, 2011-05-25 at 08:00 +0200, Igor Ribeiro Sucupira wrote:
>>>>>
>>>>> Suppose there is a heavy operation Op that in some cases takes so long
>>>>> to finish that the caller loses interest in the result and gives up.
>>>>>
>>>>> I want to perform that operation in a way that allows me to:
>>>>> 1) Interrupt its execution if it does not finish in N milliseconds.
>>>>> 2) Interrupt its execution if the calling process exits (here I'm
>>>>> already supposing Op has to be run in another Erlang process, due to
>>>>> goal 1).
>>>>>
>>>>> To implement that, it seems unidirectional linking would be needed. Is
>>>>> there another safe and convenient way to do it?
>>>>>
>>>>> The first idea I had was something like this:
>>>>>
>>>>> Parent = self(),
>>>>> Child = spawn_link(fun() -> Parent ! (catch Op) end),
>>>>> receive Result -> Result
>>>>> after N -> unlink(Child), exit(Child, timeout), timeout
>>>>> end.
>>>>>
>>>>> But, if Parent is killed by another process right after calling
>>>>> unlink, Child would be left executing.
>>>>> Another problem is that I don't want Parent to die if Child exits for
>>>>> non-timeout reasons (although it seems very unlikely in the code
>>>>> above, with the catch).
>>>>>
>>>>> I was now thinking of substituting unlink(Child) with
>>>>> process_flag(trap_exit, true) and then kill Child, receive its exit
>>>>> message, set trap_exit to false again (I'm assuming it was false), and
>>>>> finally check if there were other exit messages (suiciding if it was
>>>>> the case).
>>>>>
>>>>> But then the code would become too ugly, so I got lazy and decided to
>>>>> post to this list.  :-)
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Thanks.
>>>>> Igor.
>>>>> _______________________________________________
>>>>> erlang-questions mailing list
>>>>> 
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> 
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> --
>> 
>



More information about the erlang-questions mailing list