Merge pull request paulross#19 from miurahr/patch-docs-typo

paulross · web-flow · commit 8173a03a292a · 2023-04-22T15:50:34.000+01:00
docs: Fix typo
diff --git a/doc/sphinx/source/cpp_and_cpython.rst b/doc/sphinx/source/cpp_and_cpython.rst
@@ -14,7 +14,7 @@ It is sometimes useful to wrap up a ``PyObject*`` in a class that will manage th
 
 * Construction with a ``PyObject *`` and access this with ``operator PyObject*() const``.
 * ``PyObject **operator&()`` to reset the underlying pointer, for example when using it with ``PyArg_ParseTupleAndKeywords``.
-* Decrementing the reference count on destruction (potientially freeing the object).
+* Decrementing the reference count on destruction (potentially freeing the object).
 
 .. code-block:: cpp
 
diff --git a/doc/sphinx/source/thread_safety.rst b/doc/sphinx/source/thread_safety.rst
@@ -230,4 +230,4 @@ And that is pretty much it.
 
 .. [#f1] I won't pretend to understand all that is going on here, it does work however.
 .. [#f2] What I don't understand is why putting this code in the ``SkipList_new`` function does not work, the lock does not get initialised and segfaults typically in ``_pthread_mutex_check_init``. The order has to be: set the lock pointer NULL in ``_new``, allocate it in ``_init``, free it in ``_dealloc``.
-.. [#f3] A potiential weakness of this code is that we might be deallocating the lock *whilst the lock is acquired* which could lead to deadlock. This is very much implementation defined in ``pythreads`` and may vary from platform to platform. There is no obvious API in ``pythreads`` that allows us to determine if a lock is held so we can release it before deallocation. I notice that in the Python threading module (*Modules/_threadmodule.c*) there is an additional ``char`` field that acts as a flag to say when the lock is held so that the ``lock_dealloc()`` function in that module can release the lock before freeing the lock.
+.. [#f3] A potential weakness of this code is that we might be deallocating the lock *whilst the lock is acquired* which could lead to deadlock. This is very much implementation defined in ``pythreads`` and may vary from platform to platform. There is no obvious API in ``pythreads`` that allows us to determine if a lock is held so we can release it before deallocation. I notice that in the Python threading module (*Modules/_threadmodule.c*) there is an additional ``char`` field that acts as a flag to say when the lock is held so that the ``lock_dealloc()`` function in that module can release the lock before freeing the lock.
