7 releases
new 0.1.8 | Dec 20, 2024 |
---|---|
0.1.7 | Dec 19, 2024 |
#2014 in Development tools
204 downloads per month
Used in 2 crates
7KB
relib
relib
is a framework for reloadable dynamic libraries written in Rust.
Platforms supported
currently Linux has the best support, Windows is supported partially, macOS is not supported (not tested), see support matrix.
Overview
relib
tries to be a safe (as much as possible) runtime of native, almost normal Rust programs. Programs that can be safely unloaded (without memory leaks and crashes) without closing the whole OS process.
Since it's not possible to make this completely safe: memory leaks, UB can still happen (for example, due to some unsafe call to C library), you should only use unloading for development (see live reload example). relib
also provides imports/exports mechanism which can also be used in production.
See feature support matrix for what relib
offers to improve unloading of dynamic libraries in Rust. And for what not, check out limitations.
Examples
See examples.
Docs
See docs
of relib
crate.
Limitations
Imports/exports runtime validation
Currently, relib
doesn't check in runtime that function signatures (arguments, return types) specified in imports and exports traits (main
and before_unload
as well) are exactly the same for host and module.
ABI stability
To ensure at least something about ABI relib
checks and requires that host and module are compiled with the same rustc and relib
version.
For ABI stable types, you can use abi_stable or stabby crate for it, see abi_stable
usage example.
File descriptors and network sockets
Currently, relib
knows nothing about file descriptors or network sockets (unlike background threads) so, for example, if your program stores them in static items and does not properly close them they will leak after unloading.
note: relib provides before_unload
callback API when you need to cleanup something manually (similar to Rust Drop).
Dead locks
If your program deadlocks unloading won't work and you will have to kill the whole process.
Why dynamic libraries when we already have WASM?
If you can you should use WebAssembly since it's much more memory-safe approach. But what if WASM is not enough for you for some of these reasons: (some of which may be resolved in the future)
- you need to communicate with C++ or C
- you want to use all features of Rust (for example, multi threading, panics, backtraces may not be supported really well in WASM ecosystem)
- you've already written something in normal Rust and don't want to rewrite it to work in WASM
- you don't need sandboxing/isolation
- performance
- bugs in WASM runtimes
Resources that helped me create this tool
Awesome fasterthanlime's article ❤️ https://fasterthanli.me/articles/so-you-want-to-live-reload-rust