[Python-Dev] PEP 298

[Thomas Heller]

Scott Gilbert <xscottg@yahoo.com> writes:

> --- "Martin_v._Löwis" <martin@v.loewis.de> wrote:
> > 
> > > If you think it's an issue, the act of locking the buffer could
> > > increase the refcount too...
> > 
> > I know something is flawed. Whether this is fixed by changing the spec,
> > or by changing the implementation, I don't know.

The implementation follows the PEP, of course, so the PEP must be
changed first. Currently the uploaded patch serves as a backup store
for the changes I've done so far.

> > 
> > If the spec means "the pointer is not valid if the reference count of
> > the underlying object goes to zero", it should say so. If the spec means
> > "if the reference count goes to zero while the object is locked, Python
> > aborts", it should say so. If the spec means "the buffer will not be
> > released while it is acquired", it should say so. From reading the spec,
> > I cannot tell which one it is. From reading the implementation, I can
> > tell "it depends on the type". I thought that "depends on the type" is
> > what this API was meant to eliminate.
> > 
> 
> The object should definitely be kept alive while someone has the buffer
> locked.
> 
> I think it should be fixed by saying that PyObject_AcquireLockedReadBuffer
> and PyObject_AcquireLockedWriteBuffer will also do a Py_INCREF and that
> PyObject_ReleaseLockedBuffer will do a Py_DECREF.
> 
> If there is no disagreement, and Thomas Heller doesn't mind, I'll submit
> the changes to the PEP...  Would this be sufficient to keep the PEP alive
> (possibly in the "abandoned" state if Thomas Heller doesn't want to work on
> it for 2.4)?

I will change the PEP according to Martin's 'complaints' and Scott's
suggestions probably on Monday, but feel free to do it yourself if you
want, Scott.

If I understand the PEP process correctly, the PEP is alive until
there is a definite pronouncement on it.

> > > How would you use this at the Python level?  I don't see how it is
> > > useful outside of a C extension.
> > 
> > I want to pass buffers to fcntl, and want fcntl to change the buffer
> > in-place. Currently, fcntl will need to keep the interpreter lock for
> > that.
> > 
> > For that to work, I need to create a locked buffer, and I need to find
> > out its address. I can create a buffer using the buffer builtin, but it
> > won't be a locked one, and I need to find out its address, but I can't.
> > 

A 'locked buffer' object could be built if the PEP is implemented,
should it be part of the PEP? But if you expose the buffer address to Python
as an integer, you're living dangerous again.

Thomas