> --- Thomas Heller <thomas.heller@ion-tof.com> wrote: > > > > > This restricts the set of objects that can be buffers to statically > > > sized objects. I'd prefer that dynamically resizable objects be able to > > > be buffers. > > > > > > > ..., but I understand Neil's requirements. > > > > Can they be fulfilled by adding some kind of UnlockObject() > > call to the 'safe buffer interface', which should mean 'I won't > > use the pointer received by getsaferead/writebufferproc any more'? > > > > I assume this means any call to getsafereadpointer()/getsafewritepointer() > will increment the lock count. So the UnlockObject() calls will be > mandatory. Either that, or you'll have an explicit LockObject() call as > well. What behavior should happen when a resise is attempted while the > lock count is positive? I don't like where this is going. Let's not add locking to the buffer protocol. If an object's buffer isn't allocated for the object's life when the object is created, it should not support the "safe" version of the protocol (maybe a different name would be better), and users should not release the GIL while using on to the pointer. (Exactly which other API calls are safe while using the pointer is not clear; probably nothing that could possibly invoke the Python interpreter recursively, since that might release the GIL. This would generally mean that calls to Py_DECREF() are unsafe while holding on to a buffer pointer!) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4