Update the magic bit in examples.

python · ericsnowcurrently · Mar 1, 2022 · Feb 26, 2022 · Feb 26, 2022 · Feb 26, 2022
commit f6bab1d541bef8e1980cc3e4840c4ae48f6f8155
@@ -260,7 +260,7 @@ That means it would accidentally never be cleaned up
 On 64-bit builds, this accidental scenario is so unlikely that we need
 not worry.  Even if done deliberately by using ``Py_INCREF()`` in a
 tight loop and each iteration only took 1 CPU cycle, it would take
-2^60 cycles (on a 64-bit processor).  At a fast 5 GHz that would
+2^60 cycles (if the immortal bit were 2^60).  At a fast 5 GHz that would
 still take nearly 250,000,000 seconds (over 2,500 days)!
 
 Also note that it is doubly unlikely to be a problem because it wouldn't
@@ -275,11 +275,11 @@ same thing could be done efficiently using ``Py_SET_REFCNT()`` though
 that would be even less of an accident.)  At that point we don't
 consider it a concern of this proposal.
 
-On 32-bit builds it isn't so obvious.  The magic refcount would be 2^28.
-Using the same specs as above, it would take roughly 1 second to
-accidentally immortalize an object.  Under reasonable conditions, it
-is still highly unlikely that an object be accidentally immortalized.
-It would have to meet these criteria:
+On 32-bit builds it isn't so obvious.  Let's say the magic refcount
+were 2^30.  Using the same specs as above, it would take roughly
+4 seconds to accidentally immortalize an object.  Under reasonable
+conditions, it is still highly unlikely that an object be accidentally
+immortalized.  It would have to meet these criteria:
 
 * targeting a non-immortal object (so not one of the high-use builtins)
 * the extension increfs without a corresponding decref
@@ -288,7 +288,7 @@ It would have to meet these criteria:
 
 Under those conditions it would reach accidental immortality (on 32-bit)
 in, at most, a year if it averaged at least one of those increfs every
-158 seconds on that hypothetical workstation.  Of course, then it would
+40 seconds on that hypothetical workstation.  Of course, then it would
 have to run through the same number of (now noop-ing) decrefs before
 that one object would be effectively leaking.  This is highly unlikely,
 especially because we assume no decrefs.
@@ -552,7 +552,7 @@ _Py_IMMORTAL_REFCNT
 
 We will add two internal constants::
 
-    _Py_IMMORTAL_BIT - has the top-most available bit set
+    _Py_IMMORTAL_BIT - has the top-most available bit set (e.g. 2^62)
     _Py_IMMORTAL_REFCNT - has the two top-most available bits set
 
 The actual top-most bit depends on existing uses for refcount bits,