Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

introduce pointer stability safety locks to MultiArrayList #19327

Open
Tracked by #17719
andrewrk opened this issue Mar 16, 2024 · 2 comments · May be fixed by #19523
Open
Tracked by #17719

introduce pointer stability safety locks to MultiArrayList #19327

andrewrk opened this issue Mar 16, 2024 · 2 comments · May be fixed by #19523
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase. standard library This issue involves writing Zig code for the standard library.
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Mar 16, 2024

Extracted from #17719.

This issue is to introduce a similar API to MultiArrayList.

Related:

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library. labels Mar 16, 2024
@andrewrk andrewrk added this to the 0.15.0 milestone Mar 16, 2024
@andrewrk andrewrk changed the title introduce pointer stability locks to MultiArrayList introduce pointer stability safety locks to MultiArrayList Mar 16, 2024
@sno2
Copy link
Contributor

sno2 commented Apr 3, 2024

Should stability locks fail in cases where pointers could be invalidated, but they were not? e.g.

    const Data = struct { a: u32, b: u8 };
    var list = MultiArrayList(Data){};
    defer list.deinit(testing.allocator);

    try list.ensureTotalCapacity(testing.allocator, 1);
    list.lockPointers();
    try list.append(testing.allocator, .{ .a = 0, .b = 3 }); // should this fail?

Nevermind, seems like precedence is to fail- https://github.com/ziglang/zig/pull/17719/files#diff-8d3864cfd9fd2f29dd2b0458387c1036858fa8ac78d64517736675fbe3eaf33cR1045-R1049

sno2 added a commit to sno2/zig that referenced this issue Apr 3, 2024
sno2 added a commit to sno2/zig that referenced this issue Apr 3, 2024
@sno2 sno2 linked a pull request Apr 3, 2024 that will close this issue
@nektro
Copy link
Contributor

nektro commented Apr 3, 2024

yes because in that case where u already did an ensure capacity call, you should use appendAssumeCapacity instead of append.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase. standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants