[erlang-questions] erlang nif resource & thread safety

Benoit Chesneau <>
Mon May 2 22:15:32 CEST 2016


On Mon, May 2, 2016 at 4:24 PM Sverker Eriksson <
> wrote:

> A resource will be deallocated when
>
> * all terms created with enif_make_resource() have been garbage collected
>
> * AND the call to enif_alloc_resource() has been balanced by a call to
> enif_release_resource()
>
> * AND all calls to enif_keep_resource() have been balanced by an equal
> number of calls to enif_release_resource()
>
>
>
> On 05/02/2016 11:47 AM, Benoit Chesneau wrote:
>
> 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.
>
> So I created a nif resource that have the following properties:
> - it  is ref counted, each time a call is made to it, the counter is
> incremented and decremented when it return.
>
> A resource already has an internal ref counter, which is decremented by
> the GC and by enif_release_resource().
>
> Adding your own ref counter is probably either redundant or just plain
> wrong.
> Every call to enif_release_resource() must be balanced by a prior call
> to either enif_alloc_resource() or enif_keep_resource(). You cannot
> release a resource that is still referred to by one of more terms.
>
>
The ref counter is here mainly to makes sure that parent resources knows
everything has been cleaned since it's it's needed in the other API.


>
> - the process that create it will live until the vm is closed
>
> A resource it not tied to the process that created it,
> it is tied to the terms that refer it.
>

Oh perfect then.

>
> - write and reads to the resource are thread safe, at least the functions
> that use resource
>
> Maintaining the thread safety of the *content* of a resource
> is no different than the thread safety of any shared data in any multi
> threaded program.
>

Well of course. But Isn't there some cases where the VM fork a process
instead of using threads on some systems? I thought it did that on openbsd
for example.

>
>
> 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.
>
> It's totally fine to share resources via local ETS tables.
> The resource does not care where the terms that are keeping it alive are
> residing.
>
> The only thing that does not work is sending a resource term
> to another node or do term_to_binary/binary_to_term.
>
>
> The bottom line is:
> If enif_get_resource() succeeds, then you will obtain
> a pointer to a resource that is guaranteed to be alive
> until the ErlNifEnv of the term is invalidated.
>
>
>
> /Sverker, Erlang/OTP
>
>
>
Thanks for the detailed answer. It's useful :)

- benoît
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160502/8cc05628/attachment-0001.html>


More information about the erlang-questions mailing list