Skip to content

feat: introduce stack-allocated PyBuffer#5894

Open
winstxnhdw wants to merge 2 commits intoPyO3:mainfrom
winstxnhdw:feat/stacked-pybuffer
Open

feat: introduce stack-allocated PyBuffer#5894
winstxnhdw wants to merge 2 commits intoPyO3:mainfrom
winstxnhdw:feat/stacked-pybuffer

Conversation

@winstxnhdw
Copy link

Summary

This PR implements a pinned stack-allocated PyUntypedBuffer variant, PyUntypedBufferView.

Closes #5836

ffi::PyObject_GetBuffer(obj.as_ptr(), ptr::addr_of_mut!((*view_ptr).raw), flags)
})?;

// TODO: needs a cleanup strategy — MaybeUninit never drops its contents, so PyBuffer_Release is not currently called.
Copy link
Author

@winstxnhdw winstxnhdw Mar 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've left this incomplete for now because I want to hear more opinions on how to handle this.

Because we are using MaybeUninit to initialise Py_buffer, MaybeUninit never drops its contents, so we still need a way to call PyBuffer_Release to prevent a reference leak.

Here are some options I can think of:

  1. Use a local drop guard holding a raw pointer to the Py_buffer, released on scope exit/panic
  2. Construct an owned PyUntypedBufferView with Py_buffer::new(), letting Drop handle release, but this is not zero-cost.
  3. Call assume_init_drop() or ptr::drop_in_place() at the end of with()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider stack-allocated PyBuffer variant

1 participant