<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
A resource will be deallocated when<br>
<br>
* all terms created with enif_make_resource() have been garbage
collected<br>
<br>
* AND the call to enif_alloc_resource() has been balanced by a call
to enif_release_resource()<br>
<br>
* AND all calls to enif_keep_resource() have been balanced by an
equal number of calls to enif_release_resource()<br>
<br>
<br>
<div class="moz-cite-prefix">On 05/02/2016 11:47 AM, Benoit Chesneau
wrote:<br>
</div>
<blockquote
cite="mid:CAJNb-9rAoKk5HyX5oVVM8x8e_dzg1gwnasL5vnVFRrX3AL1bcg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">I had a look in the doc but I can't figure exactly
how much a nif resource could live outside the process that
created it, ie. how others processes can write/read to it and
how to make sure the resource will be accessible to them.
<div><br>
</div>
<div>So I created a nif resource that have the following
properties:</div>
<div><span style="line-height:1.5">- it is ref counted, each
time a call is made to it, the counter is incremented and
decremented when it return.</span><br>
</div>
</div>
</blockquote>
A resource already has an internal ref counter, which is decremented
by the GC and by enif_release_resource().<br>
<br>
Adding your own ref counter is probably either redundant or just
plain wrong.<br>
Every call to enif_release_resource() must be balanced by a prior
call<br>
to either enif_alloc_resource() or enif_keep_resource(). You cannot<br>
release a resource that is still referred to by one of more terms.<br>
<br>
<blockquote
cite="mid:CAJNb-9rAoKk5HyX5oVVM8x8e_dzg1gwnasL5vnVFRrX3AL1bcg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- the process that create it will live until the vm is
closed</div>
</div>
</blockquote>
A resource it not tied to the process that created it,<br>
it is tied to the terms that refer it.<br>
<br>
<blockquote
cite="mid:CAJNb-9rAoKk5HyX5oVVM8x8e_dzg1gwnasL5vnVFRrX3AL1bcg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- write and reads to the resource are thread safe, at least
the functions that use resource</div>
<div><br>
</div>
</div>
</blockquote>
Maintaining the thread safety of the *content* of a resource<br>
is no different than the thread safety of any shared data in any
multi threaded program.<br>
<br>
<blockquote
cite="mid:CAJNb-9rAoKk5HyX5oVVM8x8e_dzg1gwnasL5vnVFRrX3AL1bcg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>For now I was thinking to share this resources between
others processes via an ETS table. But I am wondering if
instead it shouldn't be safer to makes all the call via a nif.
With the result of creating some kind of bottleneck. </div>
</div>
</blockquote>
It's totally fine to share resources via local ETS tables.<br>
The resource does not care where the terms that are keeping it alive
are residing.<br>
<br>
The only thing that does not work is sending a resource term<br>
to another node or do term_to_binary/binary_to_term.<br>
<br>
<br>
The bottom line is:<br>
If enif_get_resource() succeeds, then you will obtain<br>
a pointer to a resource that is guaranteed to be alive<br>
until the ErlNifEnv of the term is invalidated.<br>
<br>
<br>
<br>
/Sverker, Erlang/OTP<br>
<br>
<br>
<br>
</body>
</html>