Stefan Behnel wrote:
I don't think there should always be a lock in the sense that the requestor is the only permitted accessor.
No, but there's always a lock in the sense that the provider is not allowed to move the memory while the buffer is in use. As for the other forms of locking, I'm still not sure whether that's something the buffer protocol ought to be concerning itself with. It's actually an orthogonal concept -- there's no logical reason you couldn't hold a read or write lock on an object *without* holding a move-lock on its buffer the whole time. I'm wondering whether it would be better to separate the two kinds of lock and have a different api for dealing with read/write locks. Conflating them seems to be making the buffer api confusing to talk about and complicated for a provider to implement. For example, consider a provider whose memory never moves. If the buffer api confines itself to move-locking, then that provider can ignore locking altogether. But if locking can include concepts of read/write access, it has to maintain state for the lock and handle the logic of managing it. Furthermore, the read/write aspect of the lock management logic is going to be pretty much identical for all buffer providers, suggesting it ought to be factored out somehow and implemented in one place.
Concurrent read access is common and easy to allow. Such an "always lock" scheme would disallow long-living
> buffer references. But you shouldn't be keeping long-lived buffer references in the first place. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
