introduce tokio as a dependency for roles_logic_sv2

[plebhash]

the current Actor-Model approach of plebhash@2025-04-17-channel-management-upgrade-actor-model fork branch is introducing tokio as a dependency for roles_logic_sv2

we should use this discussion to debate any potential objections against this decision

[plebhash]

one big pro here is the ability to re-export tokio from roles_logic_sv2 and avoid versioning conflicts with the application layer

[plebhash]

although roles_logic_sv2 is not no_std (which already makes it hard for embedded usage), this decision sort of "marries" roles_logic_sv2 with tokio

the big downside here is that alternative runtimes (e.g.: embassy) are forced into a "non-first-class-citizen" status, which is a pity because it means @Georges760 will need to replicate a lot of roles_logic_sv2 code into an embassy-friendly implementation

this will probably slow down esp-miner-rs

[plebhash]

Mujina remains perfectly viable however, as the Embedded Linux runtime should be able to handle both std and tokio without issues

[rkuester]

Mujina dev here. Yes, I was already resigned to using tokio for compatibility with our likely dependencies. That seems to be the deal with the devil you must make for async Rust these days.

[Georges760]

i will have a close look by the end of the week about this subject.

[Georges760]

I think it is totally fine for esp-miner-rs (or any embedded/non-tokio FW), because we already have the mining_sv2 crate (in protocols/v2/subprotocols/mining) being no_std and defining the mining related messages... So we can get inspired by this role_logic_sv2 whithout directly depending on it.

[jbesraa]

My main concern here is that it will impose async API for any package that will use roles-logic which is quite annoying in rust land. But we can expose sync API in the future if we see it is needed.

[plebhash]

alright just figured out a way to make all APIs non-async on plebhash@2025-04-17-channel-management-upgrade-actor-model

[plebhash]

the trade-off is that the main Actor Model run now lives inside this:

        tokio::task::spawn_blocking(move || {
            inner_factory.run();
        });

and also, as mentioned above, the tokio::sync::{mpsc, oneshot} were both replaced with std::sync::mpsc

[jbesraa]

Are there commits that are ready for review/you want me to review? I tried to look into ce8a65d but I can still see tokio(I don't necessarily have a problem with that, but because of your last comment mentioning changing tokio::sync to std::sync) imported, that got me confused.

[plebhash]

I forgot to push yesterday after writing these comments, apologies for the confusion there

782cc53 is the latest state of channel management module

but perhaps 0814e3c might be simpler to look at, since it also implements the same Actor Model patterns but with a much smaller scope for extranonce prefix factories

I'm currently migrating Pool and I'm noticing the need to adapt some things on channel management, so APIs might still be subject to some change, but hopefully not with regards to async vs non-async and the overall Actor Model patterns

[plebhash]

btw there's still some unnecessary &mut self left over on some inner get_* methods on the commits shared above, but they will be cleaned up

[plebhash]

closing this discussion because the work that motivated this is unlikely to materialize

for now, we don't need to introduce tokio into roles_logic_sv2

however, it's good to know that there's reasonable community consensus coming from the embedded world, so we can keep this avenue open in case we need it in the future

[plebhash]

cc @Georges760 @rkuester