> On 11 Aug 2016, at 04:46, Chris Angelico <[email protected]> wrote: > > Though tongue-in-cheek, this talk shows (along the way) some of the > costs of preemption, and thus some of the possibilities you'd open up > if you could go back to cooperation. While I don't think the time is > right for *operating systems* to go that route, it's definitely an > option for tasks within one process, where (as Nick says) you can > assume that it's not actively hostile. On the other hand, I've had > times when I have *really* appreciated preemptive thread switching, as > it's allowed me to fix problems in one of my threads by accessing > another thread interactively, so maybe the best model is a collection > of threads with a master.
As glyph notes in the blog post Nick linked, the reason threads are a problematic programming model is exactly because of their pre-emptive nature. This essentially gives you combinatoric expansion of the excecution-order-possibility-space: you must now confirm that your program is safe to running its instructions in almost any order, because that is what pre-emptive multithreading allows. Now, as you point out Chris, pre-emptive thread switching can help in weird situations, but those weird situations certainly should not be the average case! Most programmers should not be writing I/O code that is multithreaded for the same reason that most programmers shouldn’t be writing assembly code to speed up their Python programs: the benefit obtained from that approach is usually not outweighed by the increased engineering and maintenance costs. That’s not to say that there aren’t times where both of those ideas are good ideas: just that they’re uncommon, and shouldn’t be the first tool you pull out of your toolkit. While we’re talking about function colour, we should note that you don’t *have* to have function colour. A quick look at your average Twisted codebase that doesn’t use @inlineCallbacks will quickly show you that you can write an asynchronous program using nothing but synchronous function calls, so long as you are careful. And this has always been true: in my first job I worked on a cooperative-multitasking program written entirely in C, and as we all know C has absolutely no method for describing function colour. Again, so long as you are careful and don’t do any blocking I/O in your program, everything works just fine. But, here’s the rub. People hate callbacks, and people are bad at threads. Not everyone: I’m perfectly happy writing Twisted code, thank you, and I know loads of programmers who swear blind that threading is easy and they never have any problems, and they are almost certainly right, I’m not going to deny their experience of their discipline. But the reality is that writing good threaded code and writing good callback code are both harder than writing good code using coloured functions: they require care, and discipline, and foresight, and an understanding of code execution that is much more complex than what is rendered in any single function. Whereas writing code with coloured functions is *easier*: the space of possible execution flows is lower, the yield points are all clearly marked, and most of the care and discipline you need is reduced. The general long term solution to this is not to remove function colour, because it helps people. The long term solution is to develop a programming culture that says that 99% of your code should be normal functions, and only the last tiny 1% should make any statements about function colour. This is part of what the Sans-I/O project is about: demonstrating that you should avoid painting your functions as async until the last possible second, and that the fewer times you write async/await/@asyncio.coroutine <mailto:async/await/@asyncio.coroutine>/yield from the easier your life gets. Cory
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
