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

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

Add support for nuclei #1846

malivix opened this issue Mar 30, 2024 · 8 comments · May be fixed by #1848
Labels
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!

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
@stale stale bot closed this as completed Jun 9, 2024
@fzyzcjy fzyzcjy removed the awaiting Waiting for responses, PR, further discussions, upstream release, etc label Jun 21, 2024
Copy link
Contributor

github-actions bot commented Jul 5, 2024

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
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