Skip to content

[WIP] Allocators#51

Closed
gereeter wants to merge 5 commits intoGankra:masterfrom
gereeter:allocators
Closed

[WIP] Allocators#51
gereeter wants to merge 5 commits intoGankra:masterfrom
gereeter:allocators

Conversation

@gereeter
Copy link
Collaborator

This includes a (mostly) ported version of Vec. Currently, there is no documentation and the doc tests on Vec fail.

@Gankra
Copy link
Owner

Gankra commented Dec 31, 2014

If you haven't before, consider checking out: https://github.com/Gankro/raw-rs/tree/master/src/alloc

@Gankra
Copy link
Owner

Gankra commented Dec 31, 2014

Also I'm wondering: why try to roll our own allocators before @pnkfelix is done their research into the matter?

@gereeter
Copy link
Collaborator Author

To the first point: Thanks! I hadn't seen raw-rs yet, though I did see your PR in the main rust repo with a similar allocator API. That PR is actually where I got the shrink/grow idea from, and my mem_descriptor module was an attempt to generalize the _array functions.

To the second point: It seemed to me that collect-rs was the perfect place to do research about allocators, complementing what @pnkfelix is doing. Collections are going to be a big use case for parameterizing on allocators, and actually writing experimental collections that use allocators is a good way to ensure that the APIs we end up with can be used cleanly and efficiently. Also, I thought that @pnkfelix was mostly working on integration with a GC via a typed allocation layer above something raw like this.

Copy link
Owner

Choose a reason for hiding this comment

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

You can just check if new size >= desired size here.

@Gankra
Copy link
Owner

Gankra commented Jan 1, 2015

Is there any feedback in particular you're interested in at this stage?

@Gankra
Copy link
Owner

Gankra commented Jan 1, 2015

Some quick notes:

  • Composition of the array stuff is very cool!
  • I don't think there's any reason not to handle zero-sized types automatically in a good Rust allocator API. Having to write that logic as a consumer of the API is tedious and error-prone. The fact that we do now is completely legacy as far as I know. Unfortunately that might not be compatible with your design as e.g. a zero-length array is equivalent to zero-sized type; maybe that's correct, though?
  • I still think it's good to have "returns null" and "OOMs" versions of the API-- former for power-users, latter for most users.
  • Toss Vec in proto maybe? I can understand why you put it where you did, though. Your call.
  • Returning Results seems more appropriate in the shrink/grow methods, as they are legitimately failing ops.

@Gankra
Copy link
Owner

Gankra commented Jan 23, 2015

Feel free to re-open this if you find the time to flesh it out more.

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.

2 participants