[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-capi-sig
Subject:    [capi-sig]Re: Opaque handle API
From:       Carl Shapiro <carl.shapiro () gmail ! com>
Date:       2019-03-07 23:27:22
Message-ID: CANVK_QgwUL--R9TgnrprGnJKy+r1chP9pL7mAt3m8VaoF7i+5A () mail ! gmail ! com
[Download RAW message or body]

On Tue, Mar 5, 2019 at 1:59 PM Neil Schemenauer <nas-python@arctrix.com>
wrote:

> Does it help if the PyObject can have a pointer to memory allocated
> in these different ways?  It seems to me that allows most of the
> benefits but still allows the Python VM to GC PyObject memory in an
> efficient way.  So a Python extension type can still allocate some
> extra memory assocated with instances of it and there is a dealloc
> method called by the VM to clean it up again.  Just the memory for
> the PyObject itself must be allocated and deallocated by the VM
> itself.
>

An advantage to keeping the PyObject_HEAD in the regular Python heap and
having a separate pointer to off-heap memory is that memory ordering for
the PyObject_HEAD always works as expected.  For example, memory for frame
buffers is often in a write-combining area that does not respect ordering,
allowing the PyObject_HEAD fields to be observed in an inconsistent state.

This affects a Python that wishes to have better shared-memory concurrency
support (even if it's just within in its runtime) as not being able to make
assumptions about writes to a PyObject_HEAD can slow down common
operations.
_______________________________________________
capi-sig mailing list -- capi-sig@python.org
To unsubscribe send an email to capi-sig-leave@python.org
[prev in list] [next in list] [prev in thread] [next in thread]