On, Wed Aug 29, 2007, Lenard Lindstrom wrote: > 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? No. I'll explain the motivation and how the new code should work in another mail. >> 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. No, an iterable buffer is not necessary here. Especially Numpy and Numeric can not do anything useful with iterator-based objects. >> 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?) >> >> > [GC discusssion] Thanks for the links and infos. I'll look into it. > >> 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. Okay, now I get what you actually promote. For now it was pretty unclear to me. I see the point of separating the buffer into a completely own object type, which does not serve any other purpose than acting like a proxy object for Numeric, Numpy, PIL and whatever else supports buffer access. It also would allow us to solve both, the surfarray and sndarray issues with a single object type. Regards Marcus
Attachment:
pgpUZY5oJIZdr.pgp
Description: PGP signature