Perhaps something like this:<br><br>process_flag(trap_exit, true),<br>Parent = self(),<br>
Child = spawn_link(fun() -> Parent ! (catch Op) end),<br>
receive <br>  {'EXIT', ParentsParent, Reason} -><br>    exit(Reason);<br>  Result -> <br>    Result<br> after N -> <br>    unlink(Child), <br>    exit(Child, timeout), <br>    timeout<br>
end.<br><br>if you get an exit signal from the parent's parent you will exit if you are in the receive clause and you will ignore it (unless it is a kill) if you are in between the unlink and exit child?<br><br>I do however still think that this is very defensive and that the probability of getting an exit between unlink and exit is very small unless the timeout in N is exactly the same (very very close to) the timeout that the parent's parent has for exiting the parent.<br>
<br><br><br><div class="gmail_quote">On 25 May 2011 08:51, Igor Ribeiro Sucupira <span dir="ltr"><<a href="mailto:igorrs@gmail.com">igorrs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Supposing someone used the same logic (with timeout/kill) to spawn the<br>
parent process, the parent could be killed at any moment (but yeah: it<br>
would be bad luck to have that happening right after it called<br>
unlink).<br>
<br>
Thanks.<br>
<font color="#888888">Igor.<br>
</font><div><div></div><div class="h5"><br>
On Wed, May 25, 2011 at 3:20 AM, Mazen Harake <<a href="mailto:mazen.harake@gmail.com">mazen.harake@gmail.com</a>> wrote:<br>
> Why would someone "kill the parent"? Do you have processes which are<br>
> randomly choosing other processes to terminate? ;)<br>
><br>
> If your answer is "No" then I would suggest that you just kill the worker<br>
> processes that is taking to long, kill it in cold blood, imo.<br>
><br>
> There is no reason to think about too many "if"-scenarios when the scenarios<br>
> are too far fetched. Try the simple version first :)<br>
><br>
> otherwise you can either trap_exits or use monitors instead.<br>
><br>
> /M<br>
><br>
> On 25 May 2011 08:00, Igor Ribeiro Sucupira <<a href="mailto:igorrs@gmail.com">igorrs@gmail.com</a>> wrote:<br>
>><br>
>> Suppose there is a heavy operation Op that in some cases takes so long<br>
>> to finish that the caller loses interest in the result and gives up.<br>
>><br>
>> I want to perform that operation in a way that allows me to:<br>
>> 1) Interrupt its execution if it does not finish in N milliseconds.<br>
>> 2) Interrupt its execution if the calling process exits (here I'm<br>
>> already supposing Op has to be run in another Erlang process, due to<br>
>> goal 1).<br>
>><br>
>> To implement that, it seems unidirectional linking would be needed. Is<br>
>> there another safe and convenient way to do it?<br>
>><br>
>> The first idea I had was something like this:<br>
>><br>
>> Parent = self(),<br>
>> Child = spawn_link(fun() -> Parent ! (catch Op) end),<br>
>> receive Result -> Result<br>
>> after N -> unlink(Child), exit(Child, timeout), timeout<br>
>> end.<br>
>><br>
>> But, if Parent is killed by another process right after calling<br>
>> unlink, Child would be left executing.<br>
>> Another problem is that I don't want Parent to die if Child exits for<br>
>> non-timeout reasons (although it seems very unlikely in the code<br>
>> above, with the catch).<br>
>><br>
>> I was now thinking of substituting unlink(Child) with<br>
>> process_flag(trap_exit, true) and then kill Child, receive its exit<br>
>> message, set trap_exit to false again (I'm assuming it was false), and<br>
>> finally check if there were other exit messages (suiciding if it was<br>
>> the case).<br>
>><br>
>> But then the code would become too ugly, so I got lazy and decided to<br>
>> post to this list.  :-)<br>
>><br>
>> What do you think?<br>
>><br>
>> Thanks.<br>
>> Igor.<br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
</div></div></blockquote></div><br>