Campbell <cb921 at voice.co.za> writes: > Are Python/win32 Threads == Windows threads? Or are they, in the style > of ActivePerl's Threads, rather braindead? I know this is a FAQ of > sorts but I have read that document and many others in confusion still. Yes, under Win32, Python threads are Win32 threads and thus OS threads. We use them all the time in our code and they work very nicely with various blocking operations. However (and this is important), Python overall still uses a global interpreter lock to control its execution of the interpreted code. So even though you can have multiple OS threads, if any of them block while still holding the GIL, it will prevent any of your other Python code from running. Python code itself won't have this problem (the interpreter releases the GIL periodically after processing a small number of opcodes), but internal C code within the Python interpreter or in extension modules can do this. In general, anytime the Python interpreter itself (or its standard modules) make calls to the OS that might block, it will release the GIL around the code, permitting other Python code to run. The same is generally true for extension modules. However, if a piece of code forgets to do this, then the blocking operation can also block other Python threads. So an important question here is likely to ask precisely what blocking call are you using in your threads, and if that call is from some extension module, has that extension module properly released the GIL across the call? -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l at fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4