<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div style="font-family:Calibri,sans-serif; font-size:11pt">"But I still have a question: why can't we use threads for the cakes? (1
<br>
cake = 1 thread)."<br>
<br>
Because that is the wrong equality - it's really 1 baker = 1 thread.<br>
<br>
Bakers aren't free, you have to pay for each one (memory, stack space), it will take time for each one to learn how your bakery works (startup time), and you will waste some of your own time coordinating them (interthread communication).<br>
<br>
You also only have one set of baking equipment (the GIL), buying another bakery is expensive (another process) and fitting more equipment into the current one is very complicated (subinterpreters).<br>
<br>
So you either pay a high price for 2 bakers = 2 cakes, or you accept 2 bakers = 1.5 cakes (in the same amount of time). It turns out that often 1 baker can do 1.5 cakes in the same time as well, and it's much easier to reason about and implement correctly.<br>
<br>
Hope that makes sense and I'm not stretching things too far. Guess I should make this into a talk for PyCon next year.<br>
<br>
Cheers,<br>
Steve<br>
<br>
Top-posted from my Windows Phone</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:srkunze@mail.de">Sven R. Kunze</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">ý7/ý24/ý2015 14:41</span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:m.n.summerfield@googlemail.com">Mark Summerfield</a>;
<a href="mailto:python-ideas@googlegroups.com">python-ideas@googlegroups.com</a>;
<a href="mailto:python-ideas@python.org">python-ideas@python.org</a>; <a href="mailto:Steve.Dower@microsoft.com">
Steve Dower</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">Re: [Python-ideas] Concurrency Modules</span><br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi. I am back. First of all thanks for your eager participation. I would
<br>
like to catch on on Steve's and Mark's examples as they seem to be very <br>
good illustrations of what issue I still have.<br>
<br>
Steve explained why asyncio is great and Mark explained why <br>
threading+multiprocessing is great. Each from his own perspective and <br>
focusing on the internal implementation details. To me, all approaches <br>
can now be fit into this sort of table. Please, correct me if it's wrong <br>
(that is very important):<br>
<br>
# | code lives in | managed by<br>
--+---------------+-------------<br>
1 | processes | os scheduler<br>
2 | threads | os scheduler<br>
3 | tasks | event loop<br>
<br>
<br>
<br>
But the original question still stands:<br>
<br>
Which one to use?<br>
<br>
<br>
Ignoring little details like 'shared state', 'custom prioritization', <br>
etc., they all look the same to me and to what it all comes down are <br>
these little nasty details people try to explain so eagerly. Not saying <br>
that is a bad thing but it has some implications on production code I do <br>
not like and in the following I am going to explain that.<br>
<br>
Say, we have decided for approach N because of some requirements <br>
(examples from here and there, guidelines given by smart people, <br>
customer needs etc.) and wrote hundred thousand lines of code.<br>
What if these requirements change 6 years in the future?<br>
What if the maintainer of approach N decided to change it in such a way <br>
that is not compatible with our requirements anymore?<br>
From what I can see there is no easy way 'back' to use another <br>
approach. They all have different APIs, basically for: 'executing a <br>
function and returning its precious result (the cake)'.<br>
<br>
<br>
asyncio gives us the flexibility to choose a prioritization mechanism. <br>
Nice to have, because we are now independent on the os scheduler.<br>
But do we really ever need that?<br>
What is wrong with the os scheduler?<br>
Would that not mean that Mark better switches to asyncio?<br>
We don't know if we ever would need that in project A and project B. <br>
What now? Use asyncio just in case? Preemptively?<br>
<br>
<br>
@Steve<br>
Thanks for that great explanation of how asyncio works and its <br>
relationship to threads/processes.<br>
<br>
But I still have a question: why can't we use threads for the cakes? (1 <br>
cake = 1 thread). Not saying that asyncio would be a bad idea to use <br>
here, but couldn't we accomplish the same functionality by using threads?<br>
<br>
<br>
<br>
I think, after we've settled the above questions, we should change the <br>
focus from<br>
<br>
How do they work internally and what are the tiny differences? <br>
(answered greatly by Mark)<br>
<br>
to<br>
<br>
When do I use which one?<br>
<br>
<br>
The latter question actually is what counts for production code. It <br>
actually is quite interesting to know and to ponder over all the <br>
differences, dependencies, corner cases etc. However, when it actually <br>
comes down to 'executing a piece of code and returning its result', you <br>
end up deciding which approach to choose. You won't implement all 3 <br>
different ways just because it is great to see all the nasty little <br>
details to click in.<br>
<br>
<br>
On Thursday, July 9, 2015 at 11:54:11 PM UTC+1, Sven R. Kunze wrote:<br>
><br>
> In order to make a sound decision for the question: "Which one(s) do I<br>
> use?", at least the following items should be somehow defined clearly<br>
> for these modules:<br>
><br>
> 1) relationship between the modules<br>
> 2) NON-overlapping usage scenarios<br>
> 3) future development intentions<br>
> 4) ease of usage of the modules => future syntax<br>
> 5) examples<br>
<br>
</div>
</span></font>
</body>
</html>