Can I prevent task stealing in multithreaded Tokio? - Stack Overflow

As I understand it, with the multithreaded runtime a Tokio task may be moved from worker thread to worker thread during its execution via the task stealing mechanism

Is there any way to tell the runtime to keep a specific task on one thread only? That is, to prevent a particular task from being stolen by another worker once it has been started?

As I understand it, with the multithreaded runtime a Tokio task may be moved from worker thread to worker thread during its execution via the task stealing mechanism

Is there any way to tell the runtime to keep a specific task on one thread only? That is, to prevent a particular task from being stolen by another worker once it has been started?

• rust-tokio

Share Improve this question Follow asked Feb 4 at 14:31 Rob AgarRob Agar 12.5k55 gold badges5151 silver badges6363 bronze badges 2

• What are you doing that requires affinity to one particular thread? To my understanding, any task whose safety relies on thread affinity (such as stuff involving Windows COM object marshalling) cannot implement the Send trait, and thus can't be used as a Tokio task anyway. – TheHans255 Commented Feb 4 at 15:06
• ZeroMQ networking (using tmq) - it seems ok, but we've got a hard to reproduce intermittent bug that may be caused by zmq sockets not being threadsafe – Rob Agar Commented Feb 4 at 16:56

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

Unfortunately, work-stealing is an integral part of how Tokio works, and there does not appear to be a way to entirely turn it off, either globally or per-task.

Tokio does feature a "current thread" runtime, but that is likely a non-starter for your use case. A better bet would be to use a thread-per-core runtime such as glommio, which ensures that tasks spawned on a particular thread stay on that thread (and thus do not have to implement Send).

---

All that said, I admittedly don't know much about ZeroMQ, but since it has been used by multiple high-profile companies, including CERN, for at least a decade, it is highly unlikely to be inherently thread unsafe. I would guess that if your hard-to-reproduce bug is rooted in your ZeroMQ sockets, then I would hazard that this is because your Rust crate has a bug where it does not follow spec.