Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Tackling this myself atm, as a self-taught CS enthusiast reasoning about multiprocessing in python.


Are you aware how difficult this is? Python has a complicated and messy history regarding concurrency, and even as recently as 2012 the most common advice was "avoid threads and use processes." Python was late to come up with any story around concurrency.


> even as recently as 2012 the most common advice was "avoid threads and use processes."

Ok, I know in the grand scheme of things this may seem recent, but that was 12 years ago. Has the story really not changed since then?


Not really, multi-threaded parallelism is still limited by the GIL and it is best to use multiple processes instead. Unless you are using threads for I/O, or anything not using the CPU.

What has changed since then is that Python now supports single-threaded concurrency, through async-await semantics.


Adding threading to a dynamic scripting language that had a multi-decade run as a single-threaded runtime turns out to be really, really difficult, especially if the language had C extensions. They all have had one form or another of very hard time about it, because it is a legitimately difficult problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: