search

rusterlium / rustler

Safe Rust bridge for creating Erlang NIF functions
https://docs.rs/crate/rustler
Apache License 2.0
4.3k stars 224 forks source link

Introduce a means to set and use `void** priv_data` #148

Closed ghost closed 4 years ago

ghost commented 6 years ago

If there is a means to do this then I apologize and would someone please point to it or document it for easier use. The erlang NIF guide shows the load funtion as:

int (*load)(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info)

I am unable to find a way to do that with rustler but it is something I need as my NIF does some setup when the module loads and I want to be able to access that. Either there needs to be a way to use that in Rustler or documentation on how to do it could be added because I couldn't figure it out. If someone knows a way, please let me know and I will figure out and create a pull request for docs.

scrogson commented 6 years ago

@kraythen I believe this might be what you're looking for:

https://github.com/scrogson/fast_json/blob/master/native/src/lib.rs#L37-L43

ghost commented 6 years ago

That is actually a problem becuase the resource_init! macro requires you to implement it on the type in the same file. The problem is the struct I want to store in priv_data is from a third party lib. Also the priv_data isnt necessarily a resource, but could be anything.

hansihe commented 6 years ago

Why do you need to use priv_data? Is there any reason why you can't use something like a static variable?

ghost commented 6 years ago

I changed the code to use a threadlocal, however there are situations where priv_data is needed in other nifs I am working on translating from C. Some of those could be made static as well with lazy_static I suppose. However, I think the question should be does the project need to support priv_data for completeness?

hansihe commented 6 years ago

The reason why i'm hesitant to implement priv_data is because I have yet to see any usecase where it would actually be needed. Every use of it I have seen thus far could be more elegantly solved in rust by using something like a static variable. If there is a legit reason for using it, I would be happy to look at implementing it.

ghost commented 6 years ago

Sure, I get that. I refactored my stuff to use a threadlocal but because of the problems on the other issue, I cant use it. So definitely the priority is probably everything else.

JayKickliter commented 4 years ago

The user who opened this issue is no longer on GH. I think this can be closed.

evnu commented 4 years ago

Closing due to inactivity, please reopen if there is something to be done still.