[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PixelArray question

Marcus von Appen wrote:

On, Tue Aug 28, 2007, Lenard Lindstrom wrote:
[...]
This is a reasonable way to expect PixelArray locking to work. But the PixelArray also provides the buffer interface to an object. The buffer interface will allow the surfarray* module to be rewritten in a Numeric/numpy independent way. But for surface locking to work properly a PixelArray object must keep the surface locked while the object is alive.
PixelArray is also available to Pygame users. Being a Pygame specific type, should a PixelArray object lock a surface for the duration of the object? Probably not, since reliance on the garbage collector for resource management is not recommend. The context manager and the with statement were introduced to Python 2.5 to make resource management explicit and reliable. Maybe the buffer interface would be better handled by a lightweight, disposable object that does nothing else. 

In case of a plain buffer implementation the problem still exists:

   surface.lock ()
   buf = surface.get_buffer ()
   array = Numeric.array (buf)
Is this how surfarray will work? It just copies the surface data by iteration. What happens to pixels2d, etc? 


   surface.unlock ()
   # Ayeeeeee, array and buf are still valid, but not their contents.
# Instead we might have dangling pointers hanging around. 
   surface.lock ()
   with surface.get_buffer() as buf:
       do_stuff (buf)
   ...
   # __exit__ called, but buf still accessible though it should raise
   # an exception.
   do_more_stuff (buf)
   surface.unlock ()
No, the proposed buffer object would have implicit locking so that PixelArray doesn't need it. In fact the PyLifetimeLock_Type in surflock.c is a possible candidate. But by the looks of it you want an iterable buffer object for the new surfarray module. 


An explicit del() statement invokes the deallocation routine instead and
marks the variables as invalid (or does it behave in a different way?
You always talk about unreliable GC, but neither give any links nor
examples - what happens exactly in cases where it does not work as
supposed?)
I recall no explicit instructions by Python developers forbidding reliance on deallocators to release resources. But reference counting is strictly a CPython feature, and cycles and tracebacks can keep objects alive. But Numeric/numpy leave no other option. And these issues may not be relevant here anyway.
There was a thread on comp.lang.python that discussed deallocation versus context management by with statement: 

http://groups.google.com/group/comp.lang.python/browse_frm/thread/e587471d08dbfcbb/8013325573febcbd?tvc=1#8013325573febcbd

It started off with this quote by Paul Rubin in message 135 (threaded view):

"Python is not Perl and it has in principle always been defined by its
reference manual, though until fairly recently it's fostered a style
of relying on various ugly CPython artifacts like the reference
counting GC."
then jump on to messages 136-137, 161, 172, 174-225. It is long so don't feel you have to read it. I don't remember the discussion actually having links to articles by Python developers advocating any specific approach. 


I do not see any difference between those both (be it implicit locking
[PixelArray] or explicit [your proposals]) and issues that arise with
e.g. the f = open() f.close() calls. So there are no differences between
explicit or implicit locking when it comes to the usage, both suffer
from nearly the same side effects.
I just see an object being forced to be two different things, a high level interface to surface pixels and a low level buffer interface to the data. Maybe two separate types are required here: one that has explicit and automatic per-operation locking like a surface (basically what Brian Fisher is proposing), another with implicit locking done at allocation/deallocation time. If the surfarray and sndarray modules need the full features of PixelArray them the buffer could be a PixelArray subtype internal to Pygame. 

--
Lenard Lindstrom
<len-l@xxxxxxxxx>