[erlang-questions] find a nif resource by its nale

[Benoit Chesneau]

Thanks for the answer :)

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.

On Wed, Aug 23, 2017 at 12:53 AM, Guilherme Andrade <g@REDACTED> wrote:

> 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.
>
> 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.
>
> I myself usually just wrap the 'enif_make_resource' result in some
> meaningful tagged tuple and return it so that it's debug-friendlier.
>
> On 22 August 2017 at 20:38, Benoit Chesneau <bchesneau@REDACTED> wrote:
>
>> 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?
>>
>> 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?
>>
>> Benoît
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
> --
> Guilherme
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170824/14ecb8f0/attachment.htm>