Thanks for the help. After banging my head against janus.Queue and running into the same event loop binding errors no matter how I structured it, I decided to scrap the whole threaded approach.

Here’s the problem in short: janus.Queue is tightly bound to the event loop it was created in. Even if you create it inside the correct thread's loop and try to pass the reference around, as soon as you await queue.async_.put() or .get() in a different thread with a different loop, it blows up with RuntimeError: bound to a different event loop. That made it a nightmare to coordinate multiple threads, each with their own event loop — especially when I had to pass queues between four separate threads.

I actually managed to get it working for a bit by carefully initializing each queue inside the correct thread and using .sync on one side and .async_ on the other, depending on the direction of communication. But once I needed to pass another queue across threads (e.g., worker → entry → order monitor), the complexity started snowballing. At that point, the whole thing became too brittle and hard to maintain.

So I switched to using AnyIO and went fully async — no threads at all. Everything now runs as cleanly isolated tasks inside a single event loop using TaskGroup, and communication is dead simple using AnyIO’s native queues. No more event loop headaches, no more threading edge cases.

Appreciate the suggestion about culsans — looks promising and probably would’ve solved the issue technically, but going all-in on async with AnyIO ended up being the cleaner, more scalable solution in my case.