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

Feature: Scoped sub-arenas #49

Open
mb64 opened this issue Sep 1, 2020 · 4 comments
Open

Feature: Scoped sub-arenas #49

mb64 opened this issue Sep 1, 2020 · 4 comments

Comments

@mb64
Copy link

mb64 commented Sep 1, 2020

A feature that I would find useful is the ability to create scoped sections, where at the end of the section the arena will partially clear, dropping any allocations made in that section.

For example:

let arena = Arena::new();
// allocate some stuff from the arena
let x = arena.alloc(123);
let y = arena.alloc(456);
{
    let sub_arena = SubArena::new(&arena);
    // allocate more stuff from the arena
    let z = sub_arena.alloc(789);
    let w = sub_arena.alloc(4);
    // when sub_arena is dropped, the arena is partially cleared
    // z and w are dropped, but x and y are still good
}

I implemented this in my fork of typed_arena -- the changes are fairly non-intrusive and don't touch the Arena type itself (but still, of course, rely on its implementation details).

Would this feature be worth adding to the typed_arena crate? If so, I can make a PR.

@fitzgen
Copy link
Collaborator

fitzgen commented Sep 14, 2020

This crate is pretty much in maintenance-only mode, so I think it is best to leave new additions like this to external crates that either wrap and extend this crate, or fork it.

@epage
Copy link

epage commented Mar 29, 2021

This crate is pretty much in maintenance-only mode

What are the reasons for maintenance mode? Is there anything we can help out with for it to be more active?

My interests are

  • A sync version
  • An alloc that returns & instead of &mut

I'm needing to use this in a threaded context where there isn't an explicit initialization phase like some libraries provide.

I need borrows and Drop which is why bumpaloo doesn't work for me.

For a community health perspective, it seems like it'd be best having us contribute to a shared implementation, rather than forking, so we all benefit from any unsafe auditing that might happen.

@fitzgen
Copy link
Collaborator

fitzgen commented Mar 29, 2021

What are the reasons for maintenance mode? Is there anything we can help out with for it to be more active?

[...]

For a community health perspective, it seems like it'd be best having us contribute to a shared implementation, rather than forking, so we all benefit from any unsafe auditing that might happen.

I don't want to speak for other people who have been maintainers of this crate at times in the past, but lack of time/effort is the main thing for me. Organizing additional efforts around the crate is itself additional work for existing maintainers and adding new maintainers to an already-somewhat-popular crate (particularly new maintainers that one doesn't know directly or have a history of collaborating with) can be a little fraught what with potential supply chain attacks. So I'd personally prefer that someone fork this code base to revive it, rather than hand over the keys to this crate directly.

A sync version

FWIW, you can always wrap it in a Mutex. If you want something more performant than that, it isn't really something that can be bolted on top of an existing design, and would require reworking the crate from the ground up anyways.

An alloc that returns & instead of &mut

You should be able to pass &mut T to any function that accepts &T or generally convert the former into the latter with &*x so, while I could see the benefit of a dedicated method that does this conversion for you, it doesn't seem like this is a fundamental functionality thing.

I need borrows and Drop which is why bumpaloo doesn't work for me.

bumpalo::boxed::Box will run Drops for you.

@epage
Copy link

epage commented Apr 6, 2021

Looks like I have no choice but to fork but I figured some context might be useful

FWIW, you can always wrap it in a Mutex. If you want something more performant than that, it isn't really something that can be bolted on top of an existing design, and would require reworking the crate from the ground up anyways.

Unless I made a mistake, I believe this needs unsafe to adjust the lifetime from being tied to the Lock to being tied to the Arena. My hope was that users could be pushing common unsafe patterns into dependencies so we can leverage shared auditing.

bumpalo::boxed::Box will run Drops for you.

I believe this would mean an owned type is being returned by bumpalo while I need a borrowed type. I need the Arena to be responsible for dropping and not a proxy type.

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

No branches or pull requests

3 participants