Hacker News Reader

Unless I'm mistaken, switching to a single threaded tokio runtime made Send requirements go away for me.

Changing the type of runtime doesn't change the API at all.

Even in a single threaded runtime spawn requires Send and you need to use LocalSet + spawn_local for !Send futures.

I wasn't using spawn. It's an I/O bound program with a big select! loop at it's core. Rust spit out errors about Send and I made them go away by switching to flavor = "current_thread".

Would be nice if you could find it again, because from what I know of tokio I'd assume you made other unrelated changes which fixed the issue: tokio only has one runtime type, the flavour's effects are internal, the top-level future (run by Runtime::block_on) is always !Send, but from that you can only run Send futures (via spawn and spawn_blocking), unless you create a LocalSet.

current_thread doesn't even create an implicit LocalSet, if you try to `spawn_local` from the top-level of a current_thread runtime you get a panic, exactly like a multi_thread runtime.

Reply on news.ycombinator.com