Merge pull request #307 from timgates42/bugfix_typos

docs: Fix a few typos

docs/python_threads.rst

@@ -36,7 +36,7 @@ Prior to greenlet 2.0, when a thread dies, the thread's main greenlet was not
 considered to be dead. This has been changed in greenlet 2.0; however,
 observing this property is still a race condition, and, on some
 platforms (those that cannot use the C runtime to detect when a thread
-exits), not guaranteed (because of the potential for uncollectable
+exits), not guaranteed (because of the potential for uncollectible
 reference cycles to keep the Python thread state alive). In addition,
 this is considered an implementation detail and may not be true in all
 greenlet implementations.

src/greenlet/greenlet.cpp

@@ -514,7 +514,7 @@ static ThreadStateCreator& GET_THREAD_STATE()
         // NOTE: If any of this fails, we'll probably go on to hard
         // crash the process, because we're returning a reference to a
         // null pointer. we've called Py_FatalError(), but have no way
-        // to commuticate that to the caller. Since these should
+        // to communicate that to the caller. Since these should
         // essentially never fail unless the entire process is borked,
         // a hard crash with a decent C++ backtrace from the exception
         // is much more useful.
@@ -1713,7 +1713,7 @@ green_traverse(PyGreenlet* self, visitproc visit, void* arg)
     //    alive greenlets are not garbage collected
     //    anyway. This can be a problem, however, if this greenlet is
     //    never allowed to finish, and is referenced from the frame: we
-    //    have an uncollectable cycle in that case. Note that the
+    //    have an uncollectible cycle in that case. Note that the
     //    frame object itself is also frequently not even tracked by the GC
     //    starting with Python 3.7 (frames are allocated by the
     //    interpreter untracked, and only become tracked when their
@@ -1754,7 +1754,7 @@ green_is_gc(BorrowedGreenlet self)
         // would have returned 0, the tuple will take itself out of GC
         // tracking and never be investigated again. So that could
         // result in both us and the tuple leaking due to an
-        // unreachable/uncollectable reference. The same goes for
+        // unreachable/uncollectible reference. The same goes for
         // dictionaries.
         //
         // It's not a great idea to be changing our GC state on the
@@ -1921,7 +1921,7 @@ green_dealloc(PyGreenlet* self)
 
     if (self->pimpl) {
         // In case deleting this, which frees some memory,
-        // somewhow winds up calling back into us. That's usually a
+        // somehow winds up calling back into us. That's usually a
         //bug in our code.
         Greenlet* p = self->pimpl;
         self->pimpl = nullptr;

src/greenlet/greenlet_thread_state.hpp

@@ -359,7 +359,7 @@ class ThreadState {
         // then we "fell off the end" and the thread died.
         // It's possible that there is some other greenlet that
         // switched to us, leaving a reference to the main greenlet
-        // on the stack, somewhere uncollectable. Try to detect that.
+        // on the stack, somewhere uncollectible. Try to detect that.
         if (this->current_greenlet == this->main_greenlet && this->current_greenlet) {
             assert(this->current_greenlet->is_currently_running_in_some_thread());
             // Drop one reference we hold.