[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>