HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
Die Threads (Screencast)

David Beazley · Youtube · 59 HN points · 0 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention David Beazley's video "Die Threads (Screencast)".
Youtube Summary
EuroPython 2018 Keynote, July 25, 2018. Screencast. An exploration of what thread-programming could be if it were re-envisioned to secretly rely upon an async library. A lot of threads get killed in this talk.

Discussion about this talk can be found at https://forum.dabeaz.com/t/die-threads-europython-2018/320

Code for "thredo" is at https://github.com/dabeaz/thredo. However, be aware that it is "research code" and not something that's ready for production.

The editor used in this talk is Mu (https://codewith.mu).

David Beazley teaches intense in-person Python Programming and Computer Science courses in Chicago. Details at https://www.dabeaz.com/courses.html
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Nov 10, 2018 · 59 points, 25 comments · submitted by luu
dingdingdang
Looks like a super nice way of doing threads in Python, here's the rep: https://github.com/dabeaz/thredo

Sad to see that it has not received any love for last 4 months, is there another "preferred" thread lib for Python?

Waterluvian
The stdlib threading and concurrent.futures library goes a long way. It's still up to the developer to understand threading well enough before digging in. I'm not sure any library can eliminate that need.

I also use gevent a lot. I'm currently in love with cooperative multitasking.

JustSomeNobody
> Sad to see that it has not received any love for last 4 months...

Why is this a bad thing? Unless thredo is littered with bugs, who cares how old it is?

dingdingdang
Of course, but author is very clear on the early/alpha nature of the project plus there's uncertainty as to whether he will continue this as a project or not.. also he's the only contributor.

In other words, if I build a codebase to rely on something other than the stdlib it's nice to know that it'll have at least some support down the line.

dorfsmay
I use threading and manage my own pool in a list (it really isn't difficult). That's the fastest method I have found.
nicolaslem
I've been building a task queue à la Celery or Rq but with threads as a first class citizen: https://github.com/NicolasLM/spinach
coleifer
Huey supports thread, process or greenlet worker models.
jMyles
twisted.internet.threads is always, always my go-to personally. Twisted is an amazing project and has especially shined brightly in the past 3 years or so.
luhn
I haven't used Twisted for a while, what's been happening in the past 3 years?
jMyles
I'm not a core developer, so I might be mistaken or missing big things, but from my perspective, the big things are (in addition to the stuff I mentioned above how flow control compatibility):

Amber Brown took over as release manager, python 3 compatibility landed, lots of new test utilities, Glyph and some of the original authors took steps back but are still involved, IHandshakeListener (makes TLS easier), support for TLS 1.3 cypher suites (though full support is still pending PyOpenSSL I guess?), WSGIResource supports IPv6...

I maintain a Twisted-based web server called hendrix; we have integrated many of the new coolness and are fully Python 3 compatible. Check it out: https://github.com/hendrix/hendrix

richardwhiuk
Twisted doesn't support Python 3, which is problematic for some projects. I've also always found the code it produces difficult to test.
limaoscarjuliet
I've pushed Twisted on a 100M US company about 7 years ago and it has continued to work for us big time. The code - tens of thousands of lines in 20+ servers - survived Twisted upgrades for all these years without any changes (OK, there was one related to import, had to add PYTHONPATH=. to env).

Kudos to Twisted team!

None
None
jMyles
> Twisted doesn't support Python 3

No no, it now supports Python 3 wonderfully. It took a very long time, because a lot of what Twisted does was more dramatically changed from 2-3 than a lot of projects. Consider, for example, the implications of PEP-3333, which required that headers be in the native str type in Python 2, but also the native str type (ie, unicode) in Python 3. This was a tough problem. [0]

However, those days are long behind us. Not only does Twisted support Python 3, but it can interchange its own flow control (ie, the reactor) with the asyncio event loop, and also convert (and ensure) that Futures and Deferreds fire in a way that is cross-compatible. You can also use the inlineCallback decorator to see all of the new coroutine syntactic sugar.

Here's a project I'm working on right now that is Python 3.6+ with Twisted: https://github.com/nucypher/nucypher/

> I've also always found the code it produces difficult to test.

Yeah, I hear that a lot, and for my part, I've just never had that trouble, so I'm not sure how to respond. Have you ever read the "TDD with Twisted" document[1]? Also, the new pytest-twisted tooling helps quite a bit if you're using pytest.

0: https://github.com/twisted/twisted/blob/6ac66416c0238f403a8d... 1: https://twistedmatrix.com/documents/current/core/howto/trial...

None
None
richardwhiuk
https://twistedmatrix.com/trac/query?status=assigned&status=... suggests this isn't done - is that incorrect?
limaoscarjuliet
BTW, when writing in Twisted use @inlineCallbacks with yields for async code. The code reads as if it was synchronous then.

    @inlineCallbacks
    def get_index_status(self, index_id):
        uri = "{}/index-status?id={}".format(self.SERVER, index_id) #yes, no escaping, as this is silly test only
        r = yield self.get(uri)
        returnValue(r.text)
Using raw Deferreds is a big more difficult.
xapata
Not all software needs to change frequently to be useful.

https://github.com/dabeaz/thredo/issues/2

devxpy
It would be really cool to have the sort of Erlang-style processes in python -- where each process is a green process, so don't pay the cost of OS handling stuff, but at the same time you run multiple interpreters so that you still get the benefit of multiple cores [1].

Implementation-wise, this could be made simpler than removing the GIL, if we just fully give up on the concept of shared memory. (This is above my pay-grade, anyone with CPython internals knowledge, please share your thoughts!)

I've been trying to build a shared state system over message passing that doesn't use shared memory at all [2], and I have experienced that OS level processes are a high cost to pay, when you try to do things the Erlang way, launching thousands of processes.

[1] https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...

[2] https://github.com/pycampers/zproc

tyingq
There's this: http://www.gevent.org/
devxpy
Single core only :(
btown
If you need multicore performance, you likely will soon need multi-server performance, in which case you can either use multiprocessing or even containerization to run one gevent “hub” on each core across a cluster. Compared to threads, the memory overhead is minimal.
devxpy
Running one gevent hub per core seems viable. Does it support forking? Also I don't think that gevent does preemptive switching.

I can already do multi server just fine, but not everything is in the server domain. Also I don't seek multi-core usage for performance, specifically. Versatility is what I'm going for here.

An Erlang like system can be both performant and scalable to thousands of clients.

The current scope of python really only allows for either one. You can go either multiprocessing, which will give great processing power, but you can only launch so many of them. You can go asyncio route and launch millions of coroutines, but they suffer from performance issues.

_asummers
Going from single node to multi core doesn't introduce nearly the amount of complexity that making a distributed system does. Recommending that for someone who wants to use more than 1 core on their machine is not a reasonable recommendation. You're not wrong that you might wind up there, at the end, but doing that for the first step is too heavy unless you have a runtime to support those complexities more easily, as in e.g. BEAM.
miduil
In case you are wondering, the editor used at this talk is called "Mu" and got previously discussed on HN about three months ago [0].

[0]: https://news.ycombinator.com/item?id=17638067

rerx
I missed some discussion of how this is built on top of async/await.

Edit: Here is a recording of the talk where you can both see the slides and the speaker: https://www.youtube.com/watch?v=xOyJiN3yGfU

erdewit
It's built on top of threading really (imported via curio).
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.