llnl / llnl/axom

Allow user to control lifetime of Buffer object

Open
#772 0 comments 1 reaction 1 assignee View on GitHub

@nselliott is already working on this.

Since Dec 9, 2024.

App Integration design Documentation nice to have Reviewed Sidre
Dominant language
C++
Stars
196
Forks
34
Avg merge
4d 1h
Merged PRs (30d)
11

Description

Many Sidre users will never interact with *Buffer* objects directly. They are created as part of creating a *View* and released when there are no *Views* associated with the *Buffer*.

However, there are cases where the user cares about the lifetime of the *Buffer*. For example, they create a *Buffer* with ``createBuffer`` then create several *Views* which use consecutive blocks in the *Buffer*. When the *Views* are destroyed the user has no convenient way to preserve the *Buffer*.

A field should be added to the *Buffer* object to define ownership. When ``createBuffer`` is called by the user, ownership is set to the user. Calls to ``createBuffer`` internal to the library should set ownership to the library. Then when the last *View* is removed from a *Buffer* the *View* will no longer be deallocated if the user owns the *Buffer*.

If the *Buffer* is created by the library, then extracted by the user via ``getBuffer`` and used to create another *View*, the old semantics should still apply. This keeps the ownership model simple since only ``createBuffer`` defines user ownership.

Issue #674 should include a flag to force destruction of user owned *Buffers*.

When the DataStore destructor is called, all *Buffers* should continue to be destroyed.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.