Hi Antoine, I was thinking about something like this [0]. The point is, that the slice user has no way of knowing if the slice can still be safely used and who owns the memory.
You are right, of course, that it wouldn't be thread safe and we'd need a locking mechanism which prevents de-/reallocations while there is an active slice. A step back is a good idea. My use case would be to return a partially built slice on a buffer, while continuing appending to the buffer. Think delta dictionaries: while a slice of the coding table can be sent, we will have additional data to append later on. Right now it is handled by two buffers with copying between them, it could be implemented more efficiently with slices with a clear concept of ownership, I think. To build on your previous proposal: maybe some more finely grained locking mechanism, like the data_ being a shared_ptr<uint_8*>, slices grabbing a copy of it when they want to use it and releasing it afterwards? The parent would then check the couter of the shared_ptr (similar to the number of slices). That way an inactive slice wouldn't block the parent from resizing. Cheers, Dimitri. [0]: https://gist.github.com/alendit/00e4bd5f0e8a79e8ff9ebd86995f3905 On Wed, Apr 11, 2018 at 12:35 PM, Antoine Pitrou <anto...@python.org> wrote: > > Hi Dimitri, > > Le 11/04/2018 à 12:28, Dimitri Vorona a écrit : > > > > I think, it comes down to the memory ownership. While Buffer apparently > > never owns it's memory (based on the doc string), a MutableBuffer can. So > > if you slice a MutableBuffer, and the memory gets deallocated, you've got > > the same problem. > > I may be misunderstanding, but that sounds unlikely. Can you post a > concrete example? > > > Your proposed solution seems to be a safe one, we could even use > > shared_ptr::use_counts. But I'd rather invert the responsibility: a > parent > > buffer can do with it's memory as it pleases, the slices get a way of > > checking if they are still valid. > > That's inherently incorrect with multiple threads. > > I think we should step back a bit: what's the use case, and what's the > minimal way to satisfy that use case without opening a whole can of worms? > > Regards > > Antoine. >
