Menu
As per this discussion, PyMem_Malloc() requires the GIL; however, if the function is nothing more than an alias for malloc(), who cares?
530
void *PyObject_Malloc(size_t n)¶ Part of the Stable ABI. Allocates nbytes and returns a pointer of type void*to the allocated memory, or NULLif the request fails. Requesting zero bytes returns a distinct non-NULLpointer if possible, as if PyObject_Malloc(1)had been called instead. The memory will not have been initialized in any way.
Python has a pymalloc allocator optimized for small objects (smaller or equal to 512 bytes) with a short lifetime. It uses memory mappings called “arenas” with a fixed size of 256 KiB. It falls back to PyMem_RawMalloc () and PyMem_RawRealloc () for allocations larger than 512 bytes.
The GIL is a single lock on the interpreter itself which adds a rule that execution of any Python bytecode requires acquiring the interpreter lock. This prevents deadlocks (as there is only one lock) and doesn’t introduce much performance overhead. But it effectively makes any CPU-bound Python program single-threaded.
The multi-threading programmers don’t have to fret as some of the brightest minds in the Python community are working to remove the GIL from CPython. One such attempt is known as the Gilectomy. The Python GIL is often regarded as a mysterious and difficult topic.
Because it is sometimes more than simply an alias for malloc(). Sometimes it is an alias for _PyMem_DebugMalloc() and there is some global accounting there to keep track of unique memory objects. There's no real point in releasing the GIL just for a PyMem_Malloc() call, so you're probably doing something more complicated in C. If that's the case, you can simply call malloc() and not get any of the debugging stuff.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
