Commit 1cfe009b authored by Benjamin Peterson's avatar Benjamin Peterson

put notes in a ..note section

parent f6ffb4b2
...@@ -1022,18 +1022,18 @@ As we can easily check, our array is sorted now:: ...@@ -1022,18 +1022,18 @@ As we can easily check, our array is sorted now::
1 5 7 33 99 1 5 7 33 99
>>> >>>
**Important notes for callback functions:** .. note::
Make sure you keep references to :func:`CFUNCTYPE` objects as long as they are Make sure you keep references to :func:`CFUNCTYPE` objects as long as they
used from C code. :mod:`ctypes` doesn't, and if you don't, they may be garbage are used from C code. :mod:`ctypes` doesn't, and if you don't, they may be
collected, crashing your program when a callback is made. garbage collected, crashing your program when a callback is made.
Also, note that if the callback function is called in a thread created outside Also, note that if the callback function is called in a thread created
of Python's control (e.g. by the foreign code that calls the callback), ctypes outside of Python's control (e.g. by the foreign code that calls the
creates a new dummy Python thread on every invocation. This behavior is correct callback), ctypes creates a new dummy Python thread on every invocation. This
for most purposes, but it means that values stored with `threading.local` will behavior is correct for most purposes, but it means that values stored with
*not* survive across different callbacks, even when those calls are made from `threading.local` will *not* survive across different callbacks, even when
the same C thread. those calls are made from the same C thread.
.. _ctypes-accessing-values-exported-from-dlls: .. _ctypes-accessing-values-exported-from-dlls:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment