You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As explained in #13 it's not feasible to allow for "real" module unloading for rustler-based nif-modules. However, by (automatically) versioning the nif-modules we could achieve something similar:
In my rebar3_rust update branch I already place crates in versioned directories and generate a header-file that contains the location of the binaries relative to priv on build. We could now go one step further and generate a "wrapper" nif module that refers to exactly one version and make the rustler_codegen generate its name from the crate version and compile mode. A nif crate of name my_nifs with a single nif func/1 of version 1.0 would then generate a module like:
The actual module to expose this would then be recompiled on version change and look like this, where crates.hrl is regenerated on build to refer to the respective current generated module:
The user-defined my_nifs module would then, on reload, pick up a new generated module which in turn would load the new so/dll.
Since 'my_nifs_crate_1.0_release' should be generated on build, we could incorporate it into rustler_codegen's init! implementation and even add auto-generated specs.
The text was updated successfully, but these errors were encountered:
As explained in #13 it's not feasible to allow for "real" module unloading for rustler-based nif-modules. However, by (automatically) versioning the nif-modules we could achieve something similar:
In my
rebar3_rust
update branch I already place crates in versioned directories and generate a header-file that contains the location of the binaries relative topriv
on build. We could now go one step further and generate a "wrapper" nif module that refers to exactly one version and make therustler_codegen
generate its name from the crate version and compile mode. A nif crate of namemy_nifs
with a single niffunc/1
of version 1.0 would then generate a module like:The actual module to expose this would then be recompiled on version change and look like this, where
crates.hrl
is regenerated on build to refer to the respective current generated module:The user-defined
my_nifs
module would then, on reload, pick up a new generated module which in turn would load the new so/dll.Since
'my_nifs_crate_1.0_release'
should be generated on build, we could incorporate it intorustler_codegen
'sinit!
implementation and even add auto-generatedspecs
.The text was updated successfully, but these errors were encountered: