Got it. It is working. thank you very much. One question though. If one of the streams will return then select will return and both the streams will close down, right?
Select will complete/resolve and you’ll get a tuple back: the item type of the completed future and another future representing the (eventual) completion of the other future. If you don’t hold on to that other future then it’ll get dropped and its work will be canceled.
Ok, do you think the code I have written is the recommended way to handle async clients? I did this because I don't want to spawn many tasks.
Or i should handle both the streams seperately and spawn two different tasks for listening to both the streams.
by d way, how much overhead tasks put. i mean, like in erlang, every process will have 200bytes overhead, if it is golang then golang will put 2Kb per goroutine. so, i just wanted to know about this.
This depends on whether the tcp stream + mpsc form a logical unit of work or they’re valid independently. If they’re a unit then select is the way to go.
Tasks/futures in tokio are pretty lightweight - they’re basically little state machines encoded into the types. I wouldn’t worry about their overhead in terms of deciding whether to spawn “many” tasks or not. Instead, decide based on the logical aspect I mentioned in the first paragraph.
In general, for tcp, you’ll have a spawned task/future for each tcp connection.