I know I'm joining this discussion late in the game, so I apologize if my look through the list archives was not sufficiently exhaustive and this has been proposed and shot down before...
What if the locking mechanism were put into the array's memory instead of the container's memory? If the array-memory is a PyObject, then the existing reference counting mechanism can be used, instead of inventing a new one. We can introduce a new type, PyArray, that is pretty much opaque (bare minimum of methods). A PyArray is just a PyObject_HEAD (one type pointer plus the reference counter) followed by the data that would normally be there. When an array-like container allocates memory, it allocates a PyArray to store the actual data in. When a caller request a view, the container increments the PyArray's reference counter and returns a pointer to the PyArray. The caller is responsible for decrementing the reference counter when it is done with the view, so bf_releasebuffer becomes unnecessary. The container cannot reallocate the memory unless the reference counter on the PyArray is exactly 1. Basically, I'm wondering if it makes sense to move the new reference counter into the buffered memory rather than putting it in the container, so that there is only one reference counter implementation. Different question: what is a container supposed to do if a view is locking its memory and it needs to reallocate to complete some operation? I assume it would raise an exception, but it would be nice to spell this out in the PEP. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
