Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Conditional inclusion of tokio-net and tokio-signal for targets that do not support them. #541

Open
axos88 opened this issue Sep 17, 2022 · 3 comments · May be fixed by actix/actix-net#467
Open

Conditional inclusion of tokio-net and tokio-signal for targets that do not support them. #541

axos88 opened this issue Sep 17, 2022 · 3 comments · May be fixed by actix/actix-net#467

Comments

@axos88
Copy link

axos88 commented Sep 17, 2022

Expected Behavior

Actix should be able to compile on system that do not support tokio-net and tokio-signal.

Current Behavior

tokio net and signal features are currently hard-included from the actix-rt crate, although actix-rt barely uses them.

Possible Solution

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.

Your Environment

Compiling rust for an ESP32C3 target (RISCV).

  • Rust Version: rustc 1.65.0-nightly (750bd1a7f 2022-09-14)
  • Actix Version: 0.13.0
@fakeshadow
Copy link
Contributor

fakeshadow commented Oct 4, 2022 •
edited

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)

@axos88
Copy link
Author

axos88 commented Oct 6, 2022

Hey @fakeshadow, I'll try to push a PR later this week. Do you have any insight on why actix itself is more-or-less abandoned? It seemed like a great actor library for rust.
Do you know any other actor libraries with as hard type safety guarantees as actix?

@fakeshadow
Copy link
Contributor

Do you have any insight on why actix itself is more-or-less abandoned?

actix has a design conflict between it's API and Rust async/await feature. Making it impossible to migrate to async/await without fundamental change to how actix work at it's core. In other word it's either a complete API and behaviour overhaul or just leave it as is.

@axos88 axos88 linked a pull request Oct 10, 2022 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

remove hard dependency for tokio net and tokio signal axos88/actix-net
2 participants
@axos88 @fakeshadow