<div dir="ltr">Wed 17 July 2019 21:45 Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm afraid of the situation when the only resource owner is killed and resource must be destroyed by calling destructor.<div><br></div><div>It is too late to call to erlang at this time =(</div><div><br></div><div>However, your idea is interesting.  I can register some destruction manager just like a "hier" in ets and when resource is going to be killed, or its owner is going to be killed, we send a message to the "destruction manager" and it will clean without these messy cond_wait_timeout calls.</div></div></blockquote><div><br></div><div><div dir="ltr"><div>I think I understand....</div><div>In my case I do not even register a destructor callback since I do not need to.</div><div>Just some other ideas, maybe it is possible to use the<span class="gmail-bold_code gmail-bc-7"><span> enif_open_resource_type_x function to register a "down" function and then monitor your resource owner process from the thread with enif_monitor_process. I guess that the down callback would be called from within your thread and then you could cleanup in that without the need of mutexes and cond_wait_timout calls.<br></span></span></div><div><span class="gmail-bold_code gmail-bc-7"><span>Or if enif_send is called often you could check if it returns false, which means that to_pid or sender is not alive, and then perform cleanup in that case.<br></span></span></div><div><span class="gmail-bold_code gmail-bc-7"><span><a class="gmail-title_link" name="enif_open_resource_type_x" href="http://erlang.org/doc/man/erl_nif.html#enif_open_resource_type_x"></a></span></span></div><div><br></div><div>Also just to be clear, even if you start a thread from an API it will run within the erlang VM if you can call enif_send: <br></div><div><a href="http://erlang.org/pipermail/erlang-questions/2019-May/097983.html">http://erlang.org/pipermail/erlang-questions/2019-May/097983.html</a></div><div>It took me some time (and help from OTP developer) to understand this.</div><div><br></div></div></div></div></div>