2002-04-28 01:11:46 -03:00
|
|
|
/* The PyObject_ memory family: high-level object memory interfaces.
|
|
|
|
See pymem.h for the low-level PyMem_ family.
|
|
|
|
*/
|
1991-02-19 08:39:46 -04:00
|
|
|
|
2000-07-08 21:55:06 -03:00
|
|
|
#ifndef Py_OBJIMPL_H
|
|
|
|
#define Py_OBJIMPL_H
|
2000-07-31 19:19:30 -03:00
|
|
|
|
|
|
|
#include "pymem.h"
|
|
|
|
|
2000-07-08 21:55:06 -03:00
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2002-04-28 01:11:46 -03:00
|
|
|
/* BEWARE:
|
|
|
|
|
|
|
|
Each interface exports both functions and macros. Extension modules should
|
|
|
|
use the functions, to ensure binary compatibility across Python versions.
|
|
|
|
Because the Python implementation is free to change internal details, and
|
|
|
|
the macros may (or may not) expose details for speed, if you do use the
|
|
|
|
macros you must recompile your extensions with each Python release.
|
|
|
|
|
|
|
|
Never mix calls to PyObject_ memory functions with calls to the platform
|
|
|
|
malloc/realloc/ calloc/free, or with calls to PyMem_.
|
|
|
|
*/
|
|
|
|
|
1990-10-14 09:07:46 -03:00
|
|
|
/*
|
2000-05-03 20:44:39 -03:00
|
|
|
Functions and macros for modules that implement new object types.
|
2002-04-28 01:11:46 -03:00
|
|
|
|
|
|
|
- PyObject_New(type, typeobj) allocates memory for a new object of the given
|
|
|
|
type, and initializes part of it. 'type' must be the C structure type used
|
|
|
|
to represent the object, and 'typeobj' the address of the corresponding
|
|
|
|
type object. Reference count and type pointer are filled in; the rest of
|
|
|
|
the bytes of the object are *undefined*! The resulting expression type is
|
|
|
|
'type *'. The size of the object is determined by the tp_basicsize field
|
|
|
|
of the type object.
|
|
|
|
|
|
|
|
- PyObject_NewVar(type, typeobj, n) is similar but allocates a variable-size
|
|
|
|
object with room for n items. In addition to the refcount and type pointer
|
|
|
|
fields, this also fills in the ob_size field.
|
|
|
|
|
|
|
|
- PyObject_Del(op) releases the memory allocated for an object. It does not
|
|
|
|
run a destructor -- it only frees the memory. PyObject_Free is identical.
|
|
|
|
|
|
|
|
- PyObject_Init(op, typeobj) and PyObject_InitVar(op, typeobj, n) don't
|
|
|
|
allocate memory. Instead of a 'type' parameter, they take a pointer to a
|
|
|
|
new object (allocated by an arbitrary allocator), and initialize its object
|
|
|
|
header fields.
|
|
|
|
|
|
|
|
Note that objects created with PyObject_{New, NewVar} are allocated using the
|
|
|
|
specialized Python allocator (implemented in obmalloc.c), if WITH_PYMALLOC is
|
|
|
|
enabled. In addition, a special debugging allocator is used if PYMALLOC_DEBUG
|
|
|
|
is also #defined.
|
|
|
|
|
|
|
|
In case a specific form of memory management is needed (for example, if you
|
|
|
|
must use the platform malloc heap(s), or shared memory, or C++ local storage or
|
|
|
|
operator new), you must first allocate the object with your custom allocator,
|
|
|
|
then pass its pointer to PyObject_{Init, InitVar} for filling in its Python-
|
|
|
|
specific fields: reference count, type pointer, possibly others. You should
|
|
|
|
be aware that Python no control over these objects because they don't
|
|
|
|
cooperate with the Python memory manager. Such objects may not be eligible
|
|
|
|
for automatic garbage collection and you have to make sure that they are
|
|
|
|
released accordingly whenever their destructor gets called (cf. the specific
|
2000-05-03 20:44:39 -03:00
|
|
|
form of memory management you're using).
|
|
|
|
|
2002-04-28 01:11:46 -03:00
|
|
|
Unless you have specific memory management requirements, use
|
|
|
|
PyObject_{New, NewVar, Del}.
|
|
|
|
*/
|
2000-05-03 20:44:39 -03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Raw object memory interface
|
|
|
|
* ===========================
|
|
|
|
*/
|
|
|
|
|
2002-04-12 02:21:34 -03:00
|
|
|
/* Functions to call the same malloc/realloc/free as used by Python's
|
|
|
|
object allocator. If WITH_PYMALLOC is enabled, these may differ from
|
|
|
|
the platform malloc/realloc/free. The Python object allocator is
|
|
|
|
designed for fast, cache-conscious allocation of many "small" objects,
|
2002-04-28 01:11:46 -03:00
|
|
|
and with low hidden memory overhead.
|
|
|
|
|
|
|
|
PyObject_Malloc(0) returns a unique non-NULL pointer if possible.
|
|
|
|
|
|
|
|
PyObject_Realloc(NULL, n) acts like PyObject_Malloc(n).
|
|
|
|
PyObject_Realloc(p != NULL, 0) does not return NULL, or free the memory
|
|
|
|
at p.
|
|
|
|
|
|
|
|
Returned pointers must be checked for NULL explicitly; no action is
|
|
|
|
performed on failure other than to return NULL (no warning it printed, no
|
|
|
|
exception is set, etc).
|
|
|
|
|
|
|
|
For allocating objects, use PyObject_{New, NewVar} instead whenever
|
|
|
|
possible. The PyObject_{Malloc, Realloc, Free} family is exposed
|
|
|
|
so that you can exploit Python's small-block allocator for non-object
|
|
|
|
uses. If you must use these routines to allocate object memory, make sure
|
|
|
|
the object gets initialized via PyObject_{Init, InitVar} after obtaining
|
|
|
|
the raw memory.
|
|
|
|
*/
|
2002-08-12 04:21:58 -03:00
|
|
|
PyAPI_FUNC(void *) PyObject_Malloc(size_t);
|
|
|
|
PyAPI_FUNC(void *) PyObject_Realloc(void *, size_t);
|
|
|
|
PyAPI_FUNC(void) PyObject_Free(void *);
|
2000-05-03 20:44:39 -03:00
|
|
|
|
2002-04-11 23:38:45 -03:00
|
|
|
|
2000-05-03 20:44:39 -03:00
|
|
|
/* Macros */
|
2002-04-11 23:38:45 -03:00
|
|
|
#ifdef WITH_PYMALLOC
|
Years in the making.
objimpl.h, pymem.h: Stop mapping PyMem_{Del, DEL} and PyMem_{Free, FREE}
to PyObject_{Free, FREE} in a release build. They're aliases for the
system free() now.
_subprocess.c/sp_handle_dealloc(): Since the memory was originally
obtained via PyObject_NEW, it must be released via PyObject_FREE (or
_DEL).
pythonrun.c, tokenizer.c, parsermodule.c: I lost count of the number of
PyObject vs PyMem mismatches in these -- it's like the specific
function called at each site was picked at random, sometimes even with
memory obtained via PyMem getting released via PyObject. Changed most
to use PyObject uniformly, since the blobs allocated are predictably
small in most cases, and obmalloc is generally faster than system
mallocs then.
If extension modules in real life prove as sloppy as Python's front
end, we'll have to revert the objimpl.h + pymem.h part of this patch.
Note that no problems will show up in a debug build (all calls still go
thru obmalloc then). Problems will show up only in a release build, most
likely segfaults.
2006-03-26 19:27:58 -04:00
|
|
|
#ifdef PYMALLOC_DEBUG /* WITH_PYMALLOC && PYMALLOC_DEBUG */
|
2002-08-12 04:21:58 -03:00
|
|
|
PyAPI_FUNC(void *) _PyObject_DebugMalloc(size_t nbytes);
|
|
|
|
PyAPI_FUNC(void *) _PyObject_DebugRealloc(void *p, size_t nbytes);
|
|
|
|
PyAPI_FUNC(void) _PyObject_DebugFree(void *p);
|
|
|
|
PyAPI_FUNC(void) _PyObject_DebugDumpAddress(const void *p);
|
|
|
|
PyAPI_FUNC(void) _PyObject_DebugCheckAddress(const void *p);
|
|
|
|
PyAPI_FUNC(void) _PyObject_DebugMallocStats(void);
|
2002-04-12 02:21:34 -03:00
|
|
|
#define PyObject_MALLOC _PyObject_DebugMalloc
|
|
|
|
#define PyObject_Malloc _PyObject_DebugMalloc
|
|
|
|
#define PyObject_REALLOC _PyObject_DebugRealloc
|
|
|
|
#define PyObject_Realloc _PyObject_DebugRealloc
|
|
|
|
#define PyObject_FREE _PyObject_DebugFree
|
|
|
|
#define PyObject_Free _PyObject_DebugFree
|
2002-04-11 23:38:45 -03:00
|
|
|
|
|
|
|
#else /* WITH_PYMALLOC && ! PYMALLOC_DEBUG */
|
|
|
|
#define PyObject_MALLOC PyObject_Malloc
|
|
|
|
#define PyObject_REALLOC PyObject_Realloc
|
|
|
|
#define PyObject_FREE PyObject_Free
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#else /* ! WITH_PYMALLOC */
|
|
|
|
#define PyObject_MALLOC PyMem_MALLOC
|
|
|
|
#define PyObject_REALLOC PyMem_REALLOC
|
Years in the making.
objimpl.h, pymem.h: Stop mapping PyMem_{Del, DEL} and PyMem_{Free, FREE}
to PyObject_{Free, FREE} in a release build. They're aliases for the
system free() now.
_subprocess.c/sp_handle_dealloc(): Since the memory was originally
obtained via PyObject_NEW, it must be released via PyObject_FREE (or
_DEL).
pythonrun.c, tokenizer.c, parsermodule.c: I lost count of the number of
PyObject vs PyMem mismatches in these -- it's like the specific
function called at each site was picked at random, sometimes even with
memory obtained via PyMem getting released via PyObject. Changed most
to use PyObject uniformly, since the blobs allocated are predictably
small in most cases, and obmalloc is generally faster than system
mallocs then.
If extension modules in real life prove as sloppy as Python's front
end, we'll have to revert the objimpl.h + pymem.h part of this patch.
Note that no problems will show up in a debug build (all calls still go
thru obmalloc then). Problems will show up only in a release build, most
likely segfaults.
2006-03-26 19:27:58 -04:00
|
|
|
#define PyObject_FREE PyMem_FREE
|
2002-04-28 01:11:46 -03:00
|
|
|
|
2002-04-11 23:38:45 -03:00
|
|
|
#endif /* WITH_PYMALLOC */
|
|
|
|
|
2002-04-28 01:11:46 -03:00
|
|
|
#define PyObject_Del PyObject_Free
|
|
|
|
#define PyObject_DEL PyObject_FREE
|
2002-04-11 23:38:45 -03:00
|
|
|
|
|
|
|
/* for source compatibility with 2.2 */
|
2002-04-28 01:11:46 -03:00
|
|
|
#define _PyObject_Del PyObject_Free
|
2000-05-03 20:44:39 -03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Generic object allocator interface
|
|
|
|
* ==================================
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Functions */
|
2002-08-12 04:21:58 -03:00
|
|
|
PyAPI_FUNC(PyObject *) PyObject_Init(PyObject *, PyTypeObject *);
|
|
|
|
PyAPI_FUNC(PyVarObject *) PyObject_InitVar(PyVarObject *,
|
2006-02-15 13:27:45 -04:00
|
|
|
PyTypeObject *, Py_ssize_t);
|
2002-08-12 04:21:58 -03:00
|
|
|
PyAPI_FUNC(PyObject *) _PyObject_New(PyTypeObject *);
|
2006-02-15 13:27:45 -04:00
|
|
|
PyAPI_FUNC(PyVarObject *) _PyObject_NewVar(PyTypeObject *, Py_ssize_t);
|
2000-05-03 20:44:39 -03:00
|
|
|
|
|
|
|
#define PyObject_New(type, typeobj) \
|
|
|
|
( (type *) _PyObject_New(typeobj) )
|
|
|
|
#define PyObject_NewVar(type, typeobj, n) \
|
|
|
|
( (type *) _PyObject_NewVar((typeobj), (n)) )
|
|
|
|
|
2000-08-16 09:27:23 -03:00
|
|
|
/* Macros trading binary compatibility for speed. See also pymem.h.
|
2000-05-03 20:44:39 -03:00
|
|
|
Note that these macros expect non-NULL object pointers.*/
|
|
|
|
#define PyObject_INIT(op, typeobj) \
|
2001-03-22 14:26:47 -04:00
|
|
|
( (op)->ob_type = (typeobj), _Py_NewReference((PyObject *)(op)), (op) )
|
2000-05-03 20:44:39 -03:00
|
|
|
#define PyObject_INIT_VAR(op, typeobj, size) \
|
|
|
|
( (op)->ob_size = (size), PyObject_INIT((op), (typeobj)) )
|
|
|
|
|
|
|
|
#define _PyObject_SIZE(typeobj) ( (typeobj)->tp_basicsize )
|
2001-10-06 18:27:34 -03:00
|
|
|
|
2001-10-07 00:54:51 -03:00
|
|
|
/* _PyObject_VAR_SIZE returns the number of bytes (as size_t) allocated for a
|
|
|
|
vrbl-size object with nitems items, exclusive of gc overhead (if any). The
|
|
|
|
value is rounded up to the closest multiple of sizeof(void *), in order to
|
|
|
|
ensure that pointer fields at the end of the object are correctly aligned
|
|
|
|
for the platform (this is of special importance for subclasses of, e.g.,
|
|
|
|
str or long, so that pointers can be stored after the embedded data).
|
|
|
|
|
|
|
|
Note that there's no memory wastage in doing this, as malloc has to
|
|
|
|
return (at worst) pointer-aligned memory anyway.
|
2001-10-06 18:27:34 -03:00
|
|
|
*/
|
2001-10-07 00:54:51 -03:00
|
|
|
#if ((SIZEOF_VOID_P - 1) & SIZEOF_VOID_P) != 0
|
|
|
|
# error "_PyObject_VAR_SIZE requires SIZEOF_VOID_P be a power of 2"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define _PyObject_VAR_SIZE(typeobj, nitems) \
|
|
|
|
(size_t) \
|
|
|
|
( ( (typeobj)->tp_basicsize + \
|
|
|
|
(nitems)*(typeobj)->tp_itemsize + \
|
|
|
|
(SIZEOF_VOID_P - 1) \
|
|
|
|
) & ~(SIZEOF_VOID_P - 1) \
|
|
|
|
)
|
2000-05-03 20:44:39 -03:00
|
|
|
|
|
|
|
#define PyObject_NEW(type, typeobj) \
|
|
|
|
( (type *) PyObject_Init( \
|
|
|
|
(PyObject *) PyObject_MALLOC( _PyObject_SIZE(typeobj) ), (typeobj)) )
|
2001-10-06 18:27:34 -03:00
|
|
|
|
2001-10-07 00:54:51 -03:00
|
|
|
#define PyObject_NEW_VAR(type, typeobj, n) \
|
|
|
|
( (type *) PyObject_InitVar( \
|
|
|
|
(PyVarObject *) PyObject_MALLOC(_PyObject_VAR_SIZE((typeobj),(n)) ),\
|
|
|
|
(typeobj), (n)) )
|
2000-05-03 20:44:39 -03:00
|
|
|
|
|
|
|
/* This example code implements an object constructor with a custom
|
|
|
|
allocator, where PyObject_New is inlined, and shows the important
|
|
|
|
distinction between two steps (at least):
|
|
|
|
1) the actual allocation of the object storage;
|
|
|
|
2) the initialization of the Python specific fields
|
|
|
|
in this storage with PyObject_{Init, InitVar}.
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
YourObject_New(...)
|
|
|
|
{
|
|
|
|
PyObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
|
2000-05-03 20:44:39 -03:00
|
|
|
op = (PyObject *) Your_Allocator(_PyObject_SIZE(YourTypeStruct));
|
|
|
|
if (op == NULL)
|
|
|
|
return PyErr_NoMemory();
|
1993-07-28 06:05:47 -03:00
|
|
|
|
2002-04-28 01:11:46 -03:00
|
|
|
PyObject_Init(op, &YourTypeStruct);
|
1996-07-20 23:23:54 -03:00
|
|
|
|
2000-05-03 20:44:39 -03:00
|
|
|
op->ob_field = value;
|
|
|
|
...
|
|
|
|
return op;
|
|
|
|
}
|
1996-07-20 23:23:54 -03:00
|
|
|
|
2000-05-03 20:44:39 -03:00
|
|
|
Note that in C++, the use of the new operator usually implies that
|
|
|
|
the 1st step is performed automatically for you, so in a C++ class
|
2002-04-28 01:11:46 -03:00
|
|
|
constructor you would start directly with PyObject_Init/InitVar
|
|
|
|
*/
|
1996-07-20 23:23:54 -03:00
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
/*
|
|
|
|
* Garbage Collection Support
|
|
|
|
* ==========================
|
|
|
|
*/
|
2000-06-23 16:37:02 -03:00
|
|
|
|
2003-04-17 14:29:22 -03:00
|
|
|
/* C equivalent of gc.collect(). */
|
2006-03-04 16:01:53 -04:00
|
|
|
PyAPI_FUNC(Py_ssize_t) PyGC_Collect(void);
|
2003-04-17 14:29:22 -03:00
|
|
|
|
2001-08-29 20:49:28 -03:00
|
|
|
/* Test if a type has a GC head */
|
|
|
|
#define PyType_IS_GC(t) PyType_HasFeature((t), Py_TPFLAGS_HAVE_GC)
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2001-08-29 20:49:28 -03:00
|
|
|
/* Test if an object has a GC head */
|
Add Garbage Collection support to new-style classes (not yet to their
instances).
Also added GC support to various auxiliary types: super, property,
descriptors, wrappers, dictproxy. (Only type objects have a tp_clear
field; the other types are.)
One change was necessary to the GC infrastructure. We have statically
allocated type objects that don't have a GC header (and can't easily
be given one) and heap-allocated type objects that do have a GC
header. Giving these different metatypes would be really ugly: I
tried, and I had to modify pickle.py, cPickle.c, copy.py, add a new
invent a new name for the new metatype and make it a built-in, change
affected tests... In short, a mess. So instead, we add a new type
slot tp_is_gc, which is a simple Boolean function that determines
whether a particular instance has GC headers or not. This slot is
only relevant for types that have the (new) GC flag bit set. If the
tp_is_gc slot is NULL (by far the most common case), all instances of
the type are deemed to have GC headers. This slot is called by the
PyObject_IS_GC() macro (which is only used twice, both times in
gcmodule.c).
I also changed the extern declarations for a bunch of GC-related
functions (_PyObject_GC_Del etc.): these always exist but objimpl.h
only declared them when WITH_CYCLE_GC was defined, but I needed to be
able to reference them without #ifdefs. (When WITH_CYCLE_GC is not
defined, they do the same as their non-GC counterparts anyway.)
2001-10-02 18:24:57 -03:00
|
|
|
#define PyObject_IS_GC(o) (PyType_IS_GC((o)->ob_type) && \
|
|
|
|
((o)->ob_type->tp_is_gc == NULL || (o)->ob_type->tp_is_gc(o)))
|
2001-08-02 01:15:00 -03:00
|
|
|
|
2006-02-16 10:56:14 -04:00
|
|
|
PyAPI_FUNC(PyVarObject *) _PyObject_GC_Resize(PyVarObject *, Py_ssize_t);
|
2001-08-29 20:49:28 -03:00
|
|
|
#define PyObject_GC_Resize(type, op, n) \
|
|
|
|
( (type *) _PyObject_GC_Resize((PyVarObject *)(op), (n)) )
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-04-11 23:38:45 -03:00
|
|
|
/* for source compatibility with 2.2 */
|
|
|
|
#define _PyObject_GC_Del PyObject_GC_Del
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-04-28 01:11:46 -03:00
|
|
|
/* GC information is stored BEFORE the object structure. */
|
2001-10-11 15:31:31 -03:00
|
|
|
typedef union _gc_head {
|
|
|
|
struct {
|
2002-07-02 15:12:35 -03:00
|
|
|
union _gc_head *gc_next;
|
2001-10-11 15:31:31 -03:00
|
|
|
union _gc_head *gc_prev;
|
2006-03-01 12:56:25 -04:00
|
|
|
Py_ssize_t gc_refs;
|
2001-10-11 15:31:31 -03:00
|
|
|
} gc;
|
2002-02-28 15:38:51 -04:00
|
|
|
long double dummy; /* force worst-case alignment */
|
2000-06-30 02:02:53 -03:00
|
|
|
} PyGC_Head;
|
|
|
|
|
2002-05-04 02:36:06 -03:00
|
|
|
extern PyGC_Head *_PyGC_generation0;
|
2001-08-29 20:49:28 -03:00
|
|
|
|
2002-03-28 17:06:16 -04:00
|
|
|
#define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
|
|
|
|
|
2002-07-01 21:52:30 -03:00
|
|
|
#define _PyGC_REFS_UNTRACKED (-2)
|
|
|
|
#define _PyGC_REFS_REACHABLE (-3)
|
|
|
|
#define _PyGC_REFS_TENTATIVELY_UNREACHABLE (-4)
|
|
|
|
|
2001-08-29 20:49:28 -03:00
|
|
|
/* Tell the GC to track this object. NB: While the object is tracked the
|
|
|
|
* collector it must be safe to call the ob_traverse method. */
|
|
|
|
#define _PyObject_GC_TRACK(o) do { \
|
2002-03-28 17:06:16 -04:00
|
|
|
PyGC_Head *g = _Py_AS_GC(o); \
|
2002-07-01 21:52:30 -03:00
|
|
|
if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
|
|
|
|
Py_FatalError("GC object already tracked"); \
|
|
|
|
g->gc.gc_refs = _PyGC_REFS_REACHABLE; \
|
2002-05-04 02:36:06 -03:00
|
|
|
g->gc.gc_next = _PyGC_generation0; \
|
|
|
|
g->gc.gc_prev = _PyGC_generation0->gc.gc_prev; \
|
2001-10-11 15:31:31 -03:00
|
|
|
g->gc.gc_prev->gc.gc_next = g; \
|
2002-05-04 02:36:06 -03:00
|
|
|
_PyGC_generation0->gc.gc_prev = g; \
|
2001-08-29 20:49:28 -03:00
|
|
|
} while (0);
|
|
|
|
|
2002-07-02 15:12:35 -03:00
|
|
|
/* Tell the GC to stop tracking this object.
|
|
|
|
* gc_next doesn't need to be set to NULL, but doing so is a good
|
|
|
|
* way to provoke memory errors if calling code is confused.
|
|
|
|
*/
|
2001-08-29 20:49:28 -03:00
|
|
|
#define _PyObject_GC_UNTRACK(o) do { \
|
2002-03-28 17:06:16 -04:00
|
|
|
PyGC_Head *g = _Py_AS_GC(o); \
|
2002-07-01 21:52:30 -03:00
|
|
|
assert(g->gc.gc_refs != _PyGC_REFS_UNTRACKED); \
|
|
|
|
g->gc.gc_refs = _PyGC_REFS_UNTRACKED; \
|
2001-10-11 15:31:31 -03:00
|
|
|
g->gc.gc_prev->gc.gc_next = g->gc.gc_next; \
|
|
|
|
g->gc.gc_next->gc.gc_prev = g->gc.gc_prev; \
|
|
|
|
g->gc.gc_next = NULL; \
|
2001-08-29 20:49:28 -03:00
|
|
|
} while (0);
|
|
|
|
|
2002-08-12 04:21:58 -03:00
|
|
|
PyAPI_FUNC(PyObject *) _PyObject_GC_Malloc(size_t);
|
|
|
|
PyAPI_FUNC(PyObject *) _PyObject_GC_New(PyTypeObject *);
|
2006-02-15 13:27:45 -04:00
|
|
|
PyAPI_FUNC(PyVarObject *) _PyObject_GC_NewVar(PyTypeObject *, Py_ssize_t);
|
2002-08-12 04:21:58 -03:00
|
|
|
PyAPI_FUNC(void) PyObject_GC_Track(void *);
|
|
|
|
PyAPI_FUNC(void) PyObject_GC_UnTrack(void *);
|
|
|
|
PyAPI_FUNC(void) PyObject_GC_Del(void *);
|
2001-08-29 20:49:28 -03:00
|
|
|
|
|
|
|
#define PyObject_GC_New(type, typeobj) \
|
|
|
|
( (type *) _PyObject_GC_New(typeobj) )
|
|
|
|
#define PyObject_GC_NewVar(type, typeobj, n) \
|
|
|
|
( (type *) _PyObject_GC_NewVar((typeobj), (n)) )
|
2002-04-11 23:38:45 -03:00
|
|
|
|
2001-08-29 20:49:28 -03:00
|
|
|
|
2004-07-15 01:05:59 -03:00
|
|
|
/* Utility macro to help write tp_traverse functions.
|
|
|
|
* To use this macro, the tp_traverse function must name its arguments
|
|
|
|
* "visit" and "arg". This is intended to keep tp_traverse functions
|
|
|
|
* looking as much alike as possible.
|
|
|
|
*/
|
2004-07-14 16:08:17 -03:00
|
|
|
#define Py_VISIT(op) \
|
|
|
|
do { \
|
|
|
|
if (op) { \
|
|
|
|
int vret = visit((op), arg); \
|
|
|
|
if (vret) \
|
|
|
|
return vret; \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2001-08-29 20:49:28 -03:00
|
|
|
/* This is here for the sake of backwards compatibility. Extensions that
|
|
|
|
* use the old GC API will still compile but the objects will not be
|
|
|
|
* tracked by the GC. */
|
|
|
|
#define PyGC_HEAD_SIZE 0
|
|
|
|
#define PyObject_GC_Init(op)
|
|
|
|
#define PyObject_GC_Fini(op)
|
|
|
|
#define PyObject_AS_GC(op) (op)
|
|
|
|
#define PyObject_FROM_GC(op) (op)
|
2001-01-23 12:37:22 -04:00
|
|
|
|
2000-06-23 16:37:02 -03:00
|
|
|
|
2001-02-01 01:27:45 -04:00
|
|
|
/* Test if a type supports weak references */
|
2001-02-02 14:17:30 -04:00
|
|
|
#define PyType_SUPPORTS_WEAKREFS(t) \
|
|
|
|
(PyType_HasFeature((t), Py_TPFLAGS_HAVE_WEAKREFS) \
|
|
|
|
&& ((t)->tp_weaklistoffset > 0))
|
2001-02-01 01:27:45 -04:00
|
|
|
|
|
|
|
#define PyObject_GET_WEAKREFS_LISTPTR(o) \
|
|
|
|
((PyObject **) (((char *) (o)) + (o)->ob_type->tp_weaklistoffset))
|
|
|
|
|
1993-07-28 06:05:47 -03:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#endif /* !Py_OBJIMPL_H */
|