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.

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

Add support for nuclei #1846

Open
malivix opened this issue Mar 30, 2024 · 7 comments · May be fixed by #1848
Open

Add support for nuclei #1846

malivix opened this issue Mar 30, 2024 · 7 comments · May be fixed by #1848
Labels
awaiting Waiting for responses, PR, further discussions, upstream release, etc enhancement New feature or request wontfix This will not be worked on

Comments

@malivix
Copy link

malivix commented Mar 30, 2024

Is your feature request related to a problem? Please describe.
I like to use proactor-based IO system in rust for flutter

Describe the solution you'd like
Currently only this crate nuclei doing this so it should be supported by the code

Additional context
Base on what I see it's possible to add new feature like rust-async-nuclei and use this lib and should not there any problem

I can do this and create PR for it, if it's align with project

@malivix malivix added the enhancement New feature or request label Mar 30, 2024
Copy link

welcome bot commented Mar 30, 2024

Hi! Thanks for opening your first issue here! 😄

@fzyzcjy
Copy link
Owner

fzyzcjy commented Mar 31, 2024

Looks interesting! I am not an expert on the crates you mentioned, so it would be great to firstly know some background. For example, do you mean that nuclei acts as a replacement of tokio for async runtime? This does seem to be possible since frb does not enforce one specific async system (but may need a bit of refactor for some details if needed).

@fzyzcjy fzyzcjy added the awaiting Waiting for responses, PR, further discussions, upstream release, etc label Mar 31, 2024
@malivix
Copy link
Author

malivix commented Mar 31, 2024

Looks interesting! I am not an expert on the crates you mentioned, so it would be great to firstly know some background. For example, do you mean that nuclei acts as a replacement of tokio for async runtime? This does seem to be possible since frb does not enforce one specific async system (but may need a bit of refactor for some details if needed).

Yes mostly I think it's possible to be guarded by a feature like rust-async-nuclei and will be used instead of tokio
Nuclei under it will Uses async-io feature of async-global-executor by default
But can be changed to tokio
Mostly it's an abstraction on top of executors

In a asynchronous runtime there is two important sections Executor and reactor

Also there is two different patterns reactor and proactor

Both tokio and async-std is using reactor model

Nuclei is a very young crate that is implemented with proactor pattern and that is using io_uring in linux for example

@fzyzcjy
Copy link
Owner

fzyzcjy commented Mar 31, 2024

I see. I guess it would be great to allow users to define their own async runtimes. For example, currently we use https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/frb_rust/src/rust_async/io.rs (for non-web) and https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/frb_rust/src/rust_async/web.rs (for web). I guess it may be possible to abstract out a bit more s.t. we can change to arbitrary runtime. For example, instead of hardcoding tokio::task::JoinHandle, we may do

pub trait BaseAsyncRuntime {
    type JoinHandle;

    fn spawn<F>(&self, future: F) -> JoinHandle<F::Output>
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static;
}

impl BaseAsyncRuntime for SimpleAsyncRuntime {
    JoinHandle = tokio::task::JoinHandle
...
}

@malivix
Copy link
Author

malivix commented Mar 31, 2024

I see. I guess it would be great to allow users to define their own async runtimes. For example, currently we use https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/frb_rust/src/rust_async/io.rs (for non-web) and https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/frb_rust/src/rust_async/web.rs (for web). I guess it may be possible to abstract out a bit more s.t. we can change to arbitrary runtime. For example, instead of hardcoding tokio::task::JoinHandle, we may do

pub trait BaseAsyncRuntime {
    type JoinHandle;

    fn spawn<F>(&self, future: F) -> JoinHandle<F::Output>
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static;
}

impl BaseAsyncRuntime for SimpleAsyncRuntime {
    JoinHandle = tokio::task::JoinHandle
...
}

Exactly I will create a PR for you to review and then we can discuss base on code in more detail

@fzyzcjy
Copy link
Owner

fzyzcjy commented Mar 31, 2024

Looking forward to it!

@malivix malivix linked a pull request Mar 31, 2024 that will close this issue
5 tasks
Copy link

stale bot commented Jun 1, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Jun 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting Waiting for responses, PR, further discussions, upstream release, etc enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants