aboutsummaryrefslogtreecommitdiff
path: root/research
diff options
context:
space:
mode:
authorSilvio Rhatto <rhatto@riseup.net>2019-05-13 17:46:58 -0300
committerSilvio Rhatto <rhatto@riseup.net>2019-05-13 17:46:58 -0300
commit6007bb17a1918535d8dc9384c7d8f24dfbfcddb2 (patch)
treea93dcfeebca9a868757499fb497abd0d8e7514c2 /research
parent4829e63bccaf159ca72bd03f5f0afb9601064f1c (diff)
downloadblog-6007bb17a1918535d8dc9384c7d8f24dfbfcddb2.tar.gz
blog-6007bb17a1918535d8dc9384c7d8f24dfbfcddb2.tar.bz2
Research: Python: Threads and Misc
Diffstat (limited to 'research')
-rw-r--r--research/python.md31
1 files changed, 31 insertions, 0 deletions
diff --git a/research/python.md b/research/python.md
index dc05e28..40e0db5 100644
--- a/research/python.md
+++ b/research/python.md
@@ -97,6 +97,33 @@ Python encourages polymorphism:
So remember that when [copying](https://stackoverflow.com/questions/2612802/how-to-clone-or-copy-a-list#2612815)
or referencing a list.
+### Threads
+
+From [GlobalInterpreterLock](https://wiki.python.org/moin/GlobalInterpreterLock):
+
+ In CPython, the global interpreter lock, or GIL, is a mutex that protects
+ access to Python objects, preventing multiple threads from executing Python
+ bytecodes at once. This lock is necessary mainly because CPython's memory
+ management is not thread-safe. (However, since the GIL exists, other features
+ have grown to depend on the guarantees that it enforces.)
+
+ [...]
+
+ The GIL is controversial because it prevents multithreaded CPython programs
+ from taking full advantage of multiprocessor systems in certain situations.
+ Note that potentially blocking or long-running operations, such as I/O, image
+ processing, and NumPy number crunching, happen outside the GIL. Therefore it is
+ only in multithreaded programs that spend a lot of time inside the GIL,
+ interpreting CPython bytecode, that the GIL becomes a bottleneck.
+
+From: [Thread State and the Global Interpreter Lock](https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock):
+
+ When threads are created using the dedicated Python APIs (such as the threading
+ module), a thread state is automatically associated to them and the code showed
+ above is therefore correct. However, when threads are created from C (for
+ example by a third-party library with its own thread management), they don’t
+ hold the GIL, nor is there a thread state structure for them.
+
### Nice stuff
* [Verbose Regular Expressions](http://www.diveintopython3.net/regular-expressions.html#verbosere).
@@ -120,6 +147,10 @@ or referencing a list.
* [PyCharm](https://www.jetbrains.com/pycharm/).
+## Misc
+
+* [Indentation](https://www.python.org/dev/peps/pep-0008/#indentation): Use 4 spaces per indentation level.
+
## Test projects
* [Arduino Blog » How close are we to doomsday? A clock is calculating it in real time](https://blog.arduino.cc/2013/03/27/how-close-are-we-to-doomsday-clock/) ([python code](https://github.com/tomschofield/Neurotic-Armageddon-Indicator/blob/master/NAI_SERVER/nai_scraper.py) to parse [Timeline from the Bulletin of the Atomic Scientists](http://thebulletin.org/timeline)).