[Python-Dev] pre-PEP: The Safe Buffer Interface

[Neil Hodgson]

Scott Gilbert:

> First, could this be implemented by a gapped_buffer object that implements
> the locking functionality you want, but that returns simple buffers to
work
> with when the object is locked.  In other words, do we need to add this
> extra functionality up in the core protocol when it can be implemented
> specifically the way Scintilla (cool editor by the way) wants it to be in
   (Thanks)
> the Scintilla specific extension.

   Would this mean that the explicit locking completely defines the validity
of the address or is the address valid until the 'view' buffer object is
garbage collected? I would like the gapped_buffer to be put back into gapped
mode as soon as possible and depending on the lifetime of a view buffer
object is not that robust in the face of alternate Python implementations
that use non-reference-counted GC implementations (Jython / Python .Net).

> Second, if you are using mutexes to do this stuff, you'll have to be very
> careful about deadlock.

   By locking, I want to change state on the buffer from having a gap and
allowing resizes to having a static size and address which will remain valid
until an unlock. The lock and unlock are not treating the buffer as a mutex
(I'd call the operations 'acquire' and 'release' then) although mutexes may
be needed for safety in the lock and unlock implementations. It is likely
that the lock and unlock would be counted (it can be locked twice and then
won't be expandable until it is unlocked twice) and that exceptions would be
thrown for length changing operations while locked.

   If you think my particular use is out of the scope of what you are trying
to achieve then that is fine.

   Neil