On 2017-11-03, Chris Angelico <ros...@gmail.com> wrote: > On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano ><steve+pyt...@pearwood.info> wrote: >> So, all else being equal, which is likely to have more bugs? >> >> >> 1. Multiprocessing code with very little coupling between processes; or >> >> 2. Threaded code with shared data and hence higher coupling between threads? >> > > Obviously, option 1. But that's "all else being equal". How often can > you actually have your processes that decoupled? And if you can write > your code to be completely (or largely) decoupled, what's to stop you > having your *threads* equally decoupled? You're assuming that "running > in the same memoryspace" equates to "higher coupling", which is no > more proven than any other assertion.
The big difference is that with threaded code you can have accidental coupling. With multiprocessing, code you have to explicitly work to create coupling. That said, I do a lot of threading coding (in both Python and C), and have never found it particularly tricky. It does require that you understand what you're doing and probably doesn't work well if you're a stack-overflow, cargo-cult, cut-and-paste programmer. But then again, what does? -- Grant Edwards grant.b.edwards Yow! Maybe I should have at asked for my Neutron Bomb gmail.com in PAISLEY -- -- https://mail.python.org/mailman/listinfo/python-list