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

Neil Hodgson nhodgson@bigpond.net.au
Mon, 29 Jul 2002 23:52:40 +1000


Scott Gilbert:

> You could easily implement the a counting (recursive) mutex as described
> above, and it might be the case that throwing an exception on the length
> changing operations keeps the dead lock from occurring.  I'm still a bit
> confused though.

   Not as confused as I am. I don't think deadlocks or threads are that
relevant to me. The most likely situations in which I would use the buffer
interface is to perform large I/O operations without copying or when
performing asynchronous I/O to load or save documents while continuing to
run styling or linting tasks. I think its likely that the pieces of code
accessing the buffer will not be real threads, but instead be cooperating
contexts within a single-threaded UI framework so using semaphores will not
be possible.

>   1) With his PEP, there is a way to get the behavior you desire with out
> adding the complexity to the core of Python.  And with recursive/counting
> mutexes, the behavior you want is getting more complicated.

   I don't want counting mutexes. I'm not defining behaviour that needs
them.

> The "safe
> buffer protocol" is likely to cater to a wide class of users.  I could be
> wrong, but the "lockable gapped buffer protocol" probably appeals to a
much
> smaller set.

   Its not that a "lockable gapped buffer protocol" is needed. It is that
the problem with the old buffer was that the lifetime of the pointer is not
well defined. The proposal changes that by making the lifetime of the
pointer be the same as the underlying object. 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.

>   2) Any time you go from one lock (mutex, GIL, semaphore) to multiple
> locks, you can introduce deadlock states.

   My defined behaviour was "Upon receiving a lock call, it could collapse
the gap and return a stable pointer to its contents and then revert to its
normal behaviour on receiving an unlock". Where is a semaphore involved?
Without a semaphore (or equivalent) there can be no deadlock.

   Neil