<div dir="ltr">Thanks for the answer :) <div><br></div><div>I also map it in a tuple or record. I think the main idea of not having it in ETS is to remove the need of setup a another ETS table and remove some roundtrips in the process. I forgot about the liveness of the resource anyway, good call... I wish i could could use latest erlang 20 addition for it but it's not possible yet ...  So I guess I will stick to ETS for now.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 23, 2017 at 12:53 AM, Guilherme Andrade <span dir="ltr"><<a href="mailto:g@gandrade.net" target="_blank">g@gandrade.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Perhaps you could store the resource in an ETS table, which would map names (arbitrary terms, atoms, ...) to the resource itself? It would require the extra dependency of having some process own the table, and one would have to be careful with leaks, but it should work.<br><br></div><div>I think storing it in a C-land associative array could be done by always keeping at least one alive reference to it (e.g. by not calling 'enif_release_resource' while it the object lives), but avoiding resource leaks would be trickier at that point. There's a new 'enif_monitor_process' call available as of OTP 20, though; maybe one could simply make the objects owned by processes, monitor each of these processes and release the objects upon process death.<br></div><div><br></div>I myself usually just wrap the 'enif_make_resource' result in some meaningful tagged tuple and return it so that it's  debug-friendlier.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 22 August 2017 at 20:38, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">I like the idea of not passing a nif resource like ets does (ie passing a ref or a name). A idea on how this could be done in an efficient manner?<br>
<br>
I actually think to use an rw lock and a simple map in the private resource for it. But unsure what I should return on creation. Do we have to return the resource erlang term to keep it associated to the process? or simply creating it in the process will be enough?<br>
<br>
Benoît<br></div></div>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_3931148778875213681gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Guilherme<br></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>