--- Thomas Heller <thomas.heller@ion-tof.com> wrote:
> void **);
> typedef void (*releasefixedbufferproc)(PyObject *);
>
[...]
>
> If calls to these functions succeed, eventually the buffer must be
> released by a call to the releasefixedbufferproc, supplying the
> original object as argument. The releasefixedbufferproc cannot
> fail.
>
[...]
>
> void PyObject_ReleaseFixedBuffer(PyObject *obj);
>
Would it be useful to allow bf_releasefixedbuffer to return an int
indicating an exception? For instance, it could raise an exception if the
extension errantly releases more times than it has acquired (a negative
lock count). Just a thought.
>
> Python strings, unicode strings, mmap objects, and array objects
> would expose the fixed buffer interface.
>
> mmap and array objects would actually enter a locked state while
> the buffer is active, this is not needed for strings and unicode
> objects. Resizing locked array objects is not allowed and will
> raise an exception. Whether closing a locked mmap object is an
> error or will only be deferred until the lock count reaches zero
> is an implementation detail.
>
The mmap object is a good candidate for this, but I'm a little worried
about adding it to array. I'm not saying it shouldn't be done, but I can
imagine a surprized user who:
- has an existing application using the array module
- starts making use of a new extension that uses the fixed/locked
buffer interface
- gets an exception in code that never raised that exception before
With the "deferred closed" strategy for the mmap object, this can't be a
problem there. Just something to think about (or ignore :-).
Cheers,
-Scott
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
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