-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make sure all relevant erl_nif functionality is represented in some way #44
Comments
Problems
Probably going to put these features under a cargo feature since they require additional caution from the user. We might want to open an issue on OTP about these problems? |
For |
@jorendorff The erl_nif docs say: "env: The environment of the calling process. Must be NULL only if calling from a created thread" This means that by not supplying an env when doing send from within a NIF call, we are technically breaking an API invariant. |
@hansihe We always supply an env, so I think we're OK. |
@jorendorff Just checked the current implementation. It is wrong. The docs say the first env should be the env of the calling process if called from a nif, null if and only if from a calling thread. The second env should be the env the message term belongs to. The message term env is never supposed to be passed as the first argument. |
You're right. We could fix it using thread-local storage; I don't see any other way. |
I checked the source a little while ago. They don't use the first env for anything other than to improve tracing functionality. So, passing null always is fine with the current BEAM implementation. The question is if we want to take that risk, it might change in the future. |
It seems best to code to the documented API. I'll patch it. |
This API list hasn't been updated for quite a while and is missing all NIF API functions for OTP>=20. |
I wrote a small helper to find all documented NIF functions. The escript allows filtering by version prefix. |
If there is anything in particular you need, please comment below and we can work something out.
Primitives
Primitives are fully supported through
Encoder
.Atoms
Lists
Char lists
Maps
Binaries
Supported through binary abstraction.
Tuples
Resources
Exposed through resource abstraction.
Misc terms
Term utils
Type tests
Exposed as methods on NifTerm.
Scheduling
Exceptions
Supported through
rustler::Error
. It is undesirable to expose these directly:Env
Time
Misc
Threading
Rust has its own threading APIs. There are no plans to support this.
The text was updated successfully, but these errors were encountered: