Chris's Wiki :: blog/programming/ThreadsAndFork Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/ThreadsAndFork?atomcommentsDWiki2006-08-23T14:31:31ZRecent comments in Chris's Wiki :: blog/programming/ThreadsAndFork.By Chris Siebenmann on /blog/programming/ThreadsAndForktag:CSpace:blog/programming/ThreadsAndFork:b2d0478af90b7864a70dc6486dc11355330085bfChris Siebenmann<div class="wikitext"><p>Python has a confusing thread model; Python threads are real OS threads, but
the bytecode interpreter itself is single-threaded with a global lock.
Code in C-level modules can release the global interpreter lock when it
does various time-consuming things, including sleeping.</p>
<p>This is functionally similar to Ruby's model but makes it easier to work
with C-level stuff that isn't based on non-blocking IO, whether it's
C library functions like <code>gethostbyname()</code> or just significant computation.</p>
<p>(See also <a href="https://utcc.utoronto.ca/~cks/space/blog/python/UsefulPythonThreads">UsefulPythonThreads</a> and
<a href="https://utcc.utoronto.ca/~cks/space/blog/python/WhatTheGILProtects">WhatTheGILProtects</a> for more in-depth rambling about this.)</p>
</div>2006-08-23T14:31:31ZBy DanielMartin on /blog/programming/ThreadsAndForktag:CSpace:blog/programming/ThreadsAndFork:17e539bfbe1d90e591008f1fe534fc6f15e9ded2DanielMartin<div class="wikitext"><p>Are threads in Python really using the underlying OS threads? That is, I thought that threads in Python were like threads in Ruby - not using the underlying OS's threading mechanism, but instead simply relying on the interpreter keeping multiple contexts in memory and using non-blocking IO underneath.</p>
</div>2006-08-23T13:16:47Z