Dave Beazley’s Thredo library / “Die Threads” talk

A while ago Dave Beazley released GitHub - dabeaz/thredo: Thredo was an experiment - It's dead. Feel free to look around. and posted about it here:
https://forum.dabeaz.com/t/die-threads-europython-2018/ (and the screencast linked from there is a terrific watch as usual)

One interesting excerpt from the post:

Although thredo is implemented on Curio, there’s no real reason why you couldn’t make something similar work on other async libraries. The key concept that if a thread is going to block, you just make sure it happens on an async event loop, not in the OS.

Curious how Thredo compares to Trio’s own support for interacting with threads. Fundamentally there seems to be a philosophical difference — “heck yeah threads” vs. “only if you must” — which it would be interesting to understand better. Other than that, is Trio’s thread support functionally similar to Thredo’s? Any other interesting similarities or differences?

There are some plans for making Trio’s thread support more ergonomic, partly inspired by Curio. I think the main ideas are in #606 and #810.

I’m not sure Thredo is the best approach though. If you’re only using thredo primitives, then you kind of get the worst of both worlds: you have the inconvenience of rewriting all your code to use this new library, but you still have the scalability problems of threads. OTOH, if you use a mix of thredo primitives and regular blocking libraries, then the selling points like cancellation will only work for the parts of your code that use the thredo primitives, and it isn’t necessarily obvious which parts those are. So things like cancellation and timeouts will probably seem flaky. Besides, if you want a sync-flavored interface with an async system underneath, and are OK with either switching to a new set of primitives or monkeypatching everything, then you might as well use gevent, which is way more scalable than threads.

So the general strategy in Trio is to attempt to make the new async API easy to use and accessible for everyone, so that folks don’t feel the need to use threads just to avoid that weird async/await stuff. And then for the cases where you can’t switch to a new API and have to use threads, try to make that as easy as possible without hiding the inherent tradeoffs and complexity. (I actually want to tone down that “if you must” language in our docs… there are certainly some unavoidable compromises involved in using threads that folks should be aware of, but there’s no shame in using them when the upsides outweigh the downsides.)

1 Like

Perhaps https://github.com/goodboy/tractor is also competitive in this space. (If you’ll run blocking threads, may as well do it in another process.)

1 Like