find a nif resource by its nale

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

find a nif resource by its nale

Benoit Chesneau-2
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: find a nif resource by its nale

Guilherme Andrade
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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



--
Guilherme

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: find a nif resource by its nale

Loïc Hoguin-3
In reply to this post by Benoit Chesneau-2
It is my understanding that in OTP 20, magic binaries are gone, and
references are used instead:

   OTP-14205    Application(s): erts

                All uses of the magic binary kludge has been replaced
                by uses of erlang references.

                A magic binary was presented as an empty binary, but
                actually referred other data internally in the Erlang
                VM. Since they were presented as empty binaries,
                different magic binaries compared as equal, and also
                lost their internal data when passed out of an erlang
                node.

                The new usage of references has not got any of these
                strange semantic issues, and the usage of these
                references has been optimized to give the same
                performance benefits as well as memory usage benefits
                as magic binaries had.

                A couple of examples of previous uses of magic binaries
                are match specifications and NIF resources.

So it sounds like you don't need to do anything?

On 08/22/2017 09:38 PM, Benoit Chesneau 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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: find a nif resource by its nale

Max Lapshin-2
Magic binary was very convenient to make some identification for the internal resource.

Also it was the way to make mmap working (but mmap is a bad thing for reading from disk, so no problems)

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: find a nif resource by its nale

Benoit Chesneau-2
In reply to this post by Guilherme Andrade
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



--
Guilherme


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: find a nif resource by its nale

Benoit Chesneau-2
In reply to this post by Max Lapshin-2
mm not sure I follow. did you mixed the threads?

On Wed, Aug 23, 2017 at 11:53 AM, Max Lapshin <[hidden email]> wrote:
Magic binary was very convenient to make some identification for the internal resource.

Also it was the way to make mmap working (but mmap is a bad thing for reading from disk, so no problems)


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions