[Python-Dev] Re: ob_refcnt access (fwd)

[Christian Tismer]

Vladimir Marangozov wrote:
> 
> FYI, my second message on this issue didn't reach the list because
> of a stupid error of mine, so Guido and I exchanged two mails
> in private. His response to the msg below was that he thinks
> that tweaking the refcount scheme at this level wouldn't contribute
> much and that he doesn't intend to change anything on this until 2.0
> which will be rewritten from scratch.
> 
> Besides, if I want to satisfy my curiosity in hacking the refcounts
> I can do it with a small patch because I've already located the places
> where the ob_refcnt slot is accessed directly.

Well, one Euro on that issue:

> > #define _Py_GETREF(op)    (((PyObject *)op)->ob_refcnt)
> > #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n))
> >
> > Comments?
> 
> Of course, the above should be (PyObject *)(op)->ob_refcnt. Also, I forgot
> to mention that if this detail doesn't hurt code aesthetics, one (I) could
> experiment more easily all sort of weird things with refcounting...

I think if at all, this should be no typecast to stay safe.
As long as every PyObject has a refcount, this would be correct
and checked by the compiler. Why loose it?

#define _Py_GETREF(op)    ((op)->ob_refcnt)

This carries the same semantics, the same compiler check, but
adds a level of abstraction for future changes.

> I formulated the same wish for malloc & friends some time ago, that is,
> use everywhere in the core PyMem_MALLOC, PyMem_FREE etc, which would be
> defined for now as malloc, free, but nobody seems to be very excited
> about a smooth transition to other kinds of malloc. Hence, I reiterate
> this wish, 'cause switching to macros means preparing the code for the
> future, even if in the future it remains intact ;-).

I wish to incref this wish by mine.
In order to be able to try different memory allocation
strategies, I would go even further and give every
object type its own allocation macro which carries
info about the object type about to be allocated.
This costs nothing but a little macro expansion
for the C compiler, but would allow to try
new schemes, without always patching the Python source.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home