On Fri, 3 Nov 2017 07:24 am, Chris Angelico wrote: > On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster <isr...@ravnalaska.net> > wrote: >> >> Actually, that saying is about regular expressions, not threads :-) . In >> the end, threads are as good a way as handling concurrency as any other, >> and simpler than many. They have their drawbacks, of course, mainly in the >> area of overhead, and of course only multiprocessing can *really* take >> advantage of multiple cores/CPU's on a machine, but unlike regular >> expressions, threads aren't ugly or complicated. Only the details of >> dealing with concurrency make things complicated, and you'll have to deal >> with that in *any* concurrency model. >> > > Thank you. I've had this argument with many people, smart people (like > Steven), people who haven't grokked that all concurrency has costs -
Of course I grok that all concurrency has costs. Apart from comparatively rare cases of "embarrassingly parallel" algorithms, any form of concurrent or parallel processing is significantly harder than sequential code. > that threads aren't magically more dangerous than other options. There's nothing magical about it. Threads are very much UNMAGICALLY more dangerous than other options because they combine: - shared data; and - non-deterministic task switching. Having both together is clearly more dangerous than only one or the other: - async: shared data, but fully deterministic task switching; - multiprocessing: non-deterministic task switching, but by default fully isolated data. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
