[erlang-questions] Unidirectional linking?

[Joseph Wayne Norton]

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  
<igorrs@REDACTED> 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
> <bengt.kleberg@REDACTED> 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
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 
norton@REDACTED