Skip to content

Conversation

rgommers
Copy link
Member

This is a follow-up to the discussion in gh-191. It's a recommendation rather than a hard requirement to allow implementers some choice. That said, this is how things worked in practice before DLPack 1.0 as well, since there was no flag to represent read-only. Experience with JAX showed that exposing shared memory was preferred by users over raising or always making a copy of the data on the producer side.

This is a follow-up to the discussion in data-apisgh-191. It's a recommendation
rather than a hard requirement to allow implementers some choice.
That said, this is how things worked in practice before DLPack 1.0
as well, since there was no flag to represent read-only. Experience
with JAX showed that exposing shared memory was preferred by users
over raising or always making a copy of the data on the producer side.
@rgommers rgommers added Narrative Content Narrative documentation content. topic: DLPack DLPack. labels Feb 15, 2024
@leofang leofang added this to the v2023 milestone Feb 15, 2024
@leofang
Copy link
Contributor

leofang commented Feb 16, 2024

With 3 approvals, let's merge. Thanks to Ralf and all.

@leofang leofang merged commit ba787e3 into data-apis:main Feb 16, 2024
@rgommers rgommers deleted the dlpack-readonly-note branch February 16, 2024 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Narrative Content Narrative documentation content. topic: DLPack DLPack.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants