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)
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 ()
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 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 assume the same applies to sndarray.
Yes, it does.
Regards
Marcus
Attachment:
pgpJFFy4IyWtH.pgp
Description: PGP signature