<div dir="ltr"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Also, AFAIK Ruby has a GIL much like Python. I think it's time to start a PR offensive explaining why these are not the problem the trolls make them out to be, and how you simply have to use different patterns for scaling in some languages than in others.</blockquote>
<br>GIL + Threads = Fibers<br><br>CPython doesn't have threads but it calls its fibers "threads" which causes confusion and disappointment. The underlying implementation is not important eg when you implement a "lock" using "events" does the lock become an event? No. This is a PR disaster.<br>
<br>100% agree we need a PR offensive but first we need a strategy. Erlang champions the actor/message paradigm so they dodge the threading bullet completely. What's the python championed parallelism paradigm? It should be on the front page of <a href="http://python.org">python.org</a> and in the first paragraph of wikipedia on python.<br>
<br><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">One of the Lua authors said this about threads:<br>
(I can't remember the quote so I will paraphrase)<br>"How can you program in a language where 'a = a + 1' is not deterministic?"<br>Indeed.</blockquote><br>Anyone who cares enough about performance doesn't mind that 'a = a + 1' is only as deterministic as you design it to be with or without locks. Multiprocessing has this same problem btw.<br>
<br><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">What Python needs are better libraries for concurrent programming based on processes and coroutines.</blockquote>
<br>The killer feature for threads (vs multiprocessing) is access to shared state with nearly zero overhead.<br> <div><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And note that a single-threaded event-driven process can serve 100,000 open sockets -- while no JVM can create 100,000 threads.</blockquote> <br>Graphics engines, simulations, games, etc don't want 100,000 threads, they just want true threads as many as there are CPU's.<br>
<br><br>Yuval</div></div>