-
Notifications
You must be signed in to change notification settings - Fork 142
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
Move away from async-channel
#1389
Comments
@Fi3 could you provide us some insight into what were the original motivations for mixing |
as a consequence of stratum-mining#1433 and stratum-mining#1389
as a consequence of stratum-mining#1433 and stratum-mining#1389
as a consequence of stratum-mining#1433 and stratum-mining#1389
I think cause to sketch up something fast we needed a mpmc channel (not present in tokio) but really don't remember. |
aint the equivalent to mpmc is broadcast channel from tokio? also, in which cases did you need the mpmc channel? |
just guessing I really don't remember have been a lot of time ago |
btw if there is a reason is more something that have to do with getting a working example faster. Removed that dep from demand codebase has been one of the first thing that I did when I ported the code |
Can you provide more info on which channels are using now? |
mpsc for communicate with the connection handler: https://github.com/demand-open-source/demand-sv2-connection/blob/master/src/noise_connection_tokio.rs#L5 |
I think that I use mpsc almost everywhere maybe some oneshoot in the pool |
not sure if I answered your question? |
yep in the pool I use the oneshot for handle authentication. in the cli there are several broadcast https://github.com/search?q=repo%3Ademand-open-source%2Fdemand-cli+broadcast&type=code |
Yup, thank you |
A small glimpse into my exploration of the issue: Broadcast Channel (Tokio):MPMC (async-channel):In the case of an MPMC (Multi-Producer Multi-Consumer) channel, message retrieval follows a work-stealing mechanism, meaning that any available consumer can receive a message based on runtime scheduling, such as its position in the task queue. However, this behavior does not align with role-based processing, where specific consumers should receive specific messages. Which means only a single receiver is being used, otherwise each receiver might be getting different messages. Currently, our channel management in roles could be simplified. Instead of using an MPMC channel, we might only need to pass a single receiver to each role to access incoming messages, eliminating the need for multiple cloned receivers. The only reason we are using an MPMC channel right now is its clonable nature. Given how roles are currently structured—where a clones of receivers are shared across threads for access control—this approach might not be optimal. Instead, restructuring the way channels are passed across tasks could help simplify the design and potentially remove the need for an MPMC channel. From a high-level perspective, each role only requires a receiver to get messages from other role entities. This could be achieved using an MPSC channel instead of MPMC, since a role only needs one receiver instance. However, the main reason we currently use MPMC is to allow cloning the receiver. |
as a consequence of stratum-mining#1433 and stratum-mining#1389
Motivation: We want to align the networking/communication layer to use only one external crate. Currently the code mixes
tokio
channels withasync-channel
channels. Removing the later should give us more confidence and improve the reliability of the code.From
async-channel
only multi-producer-multi-consumer channels are used, when moving those totokio
one should reevaluate this assumption.This task should be completed across all roles. The final result should have
async-channel
fully removed fromroles
workspace.tokio
channels https://tokio.rs/tokio/tutorial/channelsThe text was updated successfully, but these errors were encountered: