Add Futures to a join! while it is being polled

[edgarogh]

Hello,

I'm making a TCP server and I'd like all clients to be handled on the same thread. Well, actually it's a bit more complex, I'd like to group them in a certain way and have each group handled by one single task (because of the way they will access shared resources, it's a lot simpler like this and doesn't require locking Mutexes constantly). For the time being, let's assume that I just want a single-threaded TCP server, and I'll work out how to do the rest from there.

Essentially, a TCP server corresponds to:

• A main loop that accepts clients
• As many client handlers as needed, which are their own task (in the general sense, not necessarily a tokio "task", especially not for what I want to do)

As far as I know, tokio tasks may run on different threads, hence tokio::spawn requiring Send on the future and its output. What I'd like is something more like tokio::join!, but in a way that allows me to:

• Start it with an initial task (the accepting loop)
• From this loop, insert new tasks (while the loop is being polled by the runtime)

I've read the docs of the JoinSet type, which might be related to what I want to do and has promising signatures, but it is unstable and I don't fully understand how it really works.

Any ideas? Thanks in advance.

---

How I fixed it

    let server = TcpListener::bind(addr).await?;

    let mut handlers = FuturesUnordered::new();

    loop {
        tokio::select! {
            biased; // No need to use a PRNG here, we start by trying to accept, then poll the handlers
            res = server.accept() => {
                let (tcp_stream, _socket_addr) = res?;
                handlers.push(handle_client(tcp_stream));
            }
            _ = handlers.next() => { } // Poll the handlers
        };
    }

[Darksonn]

The JoinSet type works by spawning actual tasks, so if you are using a multi-threaded runtime, this means that the tasks can end up on different threads. One option you could go for is the FuturesUnordered utility, which can let you run them inside a single task, however running many things inside a single task is somewhat inefficient. It's better to spawn them as separate tasks.

I recommend that you use a single-threaded runtime and use tokio::spawn (or a JoinSet) to spawn them.

[edgarogh]

I'm making a library so I don't really have access to the runtime (and probably shouldn't try to change its settings anyways). FuturesUnordered looks suited for my use case. Thanks a lot !

---

And regarding the inefficiency of tasks, I'll have to do benchmarks, but basically each "group" of client has a shared object that I need to give a mutable reference of to a handler function whenever clients send me data.

• If each client has their own task, I will have to use a Mutex per group and lock it for every received message.
• If I use one task for each group of client, I will be able to receive and process messages one after the other, and thus I can simply borrow the mutable shared object without any overhead

Thanks for the info though, I wouldn't even have tried trying both implementations if I hadn't been made aware.