On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James <rho...@kynesim.co.uk> wrote: > On 02/11/17 20:24, Chris Angelico wrote: >> >> Thank you. I've had this argument with many people, smart people (like >> Steven), people who haven't grokked that all concurrency has costs - >> that threads aren't magically more dangerous than other options. > > > I'm with Steven. To be fair, the danger with threads is that most people > don't understand thread-safety, and in particular don't understand either > that they have a responsibility to ensure that shared data access is done > properly or what the cost of that is. I've seen far too much thread-based > code over the years that would have been markedly less buggy and not much > slower if it had been written sequentially.
Yes, but what you're seeing is that *concurrent* code is more complicated than *sequential* code. Would the code in question have been less buggy if it had used multiprocessing instead of multithreading? What if it used explicit yield points? Multiprocessing brings with it a whole lot of extra complications around moving data around. Multithreading brings with it a whole lot of extra complications around NOT moving data around. Yield points bring with them the risk of locking another thread out unexpectedly (particularly since certain system calls aren't async-friendly on certain OSes). All three models have their pitfalls. It's not that threads are somehow worse than every other model. ChrisA -- https://mail.python.org/mailman/listinfo/python-list