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

Neil Hodgson nhodgson@bigpond.net.au
Tue, 30 Jul 2002 09:50:43 +1000


Scott Gilbert:

> What happens when you've locked the buffer and passed a pointer to the I/O
> system for an asynchronous operation, but before that operation has
> completed, your main program wants to resize the buffer due to a user
> generated event?

   That is up to the application or class designer. There are three
reasonable responses I see: throw an exception, buffer the user event, or
ignore the user event. The only thing guaranteed by providing the safe
buffer interface is that the pointer will remain valid.

> >    I don't want counting mutexes. I'm not defining behavior that needs
> > them.
> >
>
> You said you wanted the locks to keep a count.  So that you could call
> acquire() multiple times and have the buffer not truly become unlocked
> until release() was called the same amount of times.  I'm willing to adopt
> any terminology you want for the purpose of this discussion.  I think I
> understand the semantics or the counting operation, but I want to
> understand more what actually happens when the buffer is locked.

   When the buffer is locked, it returns a pointer and promises that the
pointer will remain valid until the buffer is unlocked.

   The buffer interface could be defined either to allow multiple (counted)
locks or to fail further lock attempts. Counted locks would be applicable in
more circumstances but require more implementation. I would prefer counted
but it is not that important as a counting layer can be implemented over a
single lock interface if needed.

   Neil