actix-rt is mostly aiming to drive actix-web nowadays leaving actix an after thought. You are welcomed to open pr to make it more conservative with feature flags. I personally would perfer to opt-out mentioned tokio features.(So dependent crates don't observe breaking feature change)
Conditional inclusion of tokio-net and tokio-signal for targets that do not support them. #541
Actix should be able to compile on system that do not support tokio-net and tokio-signal.
tokio net and signal features are currently hard-included from the actix-rt crate, although actix-rt barely uses them.
Create a feature gate that will enable inclusion of tokio-signal and tokio-net. Make it included by default, to remain backward compatible.
tokio-signal is only pub used from actix-rt::signal, and that module should only be compiled if tokio-signal is explicitly asked for by the user of the actix library.
actix::net provides the ActixStream, and could be left out, if unused, although I'm not particularly sure why tokio::net is required for ActixStream support. The same gate should be used for default_tokio_runtime calling enable_io or not.
Steps to Reproduce (for bugs)
include actix = "*" for a "riscv32imc-esp-espidf" target, using esp-idf OS, using std.
Can try to provide a minimal repro project if necessary, although I don't think there is need for one.
Compiling rust for an ESP32C3 target (RISCV).