linked_list_allocator update for AllocRef and spinning_top

[sbechet]

See #25

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @korken89 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[jonas-schievink]

It seems that #25 is not actually an issue that needs fixing, since it only needs a patch version bump. Changes look good to me though.

bors r+

[bors]

Canceled

[sbechet]

I don't know why the two pull request come to only one. A friend help me for #27

[sbechet]

what's wrong with bors?

[kanishkarj]

Hey, I am facing this issue too, I guess the update to linked_list_allocator is kind of necessary..

[sbechet]

Where are you code owner :)
Is this code so bad?

[therealprof]

@sbechet Would you mind rebasing/squashing this? The history is a bit messy.
@jonas-schievink Is the CS okay to use here?

[jonas-schievink]

@therealprof We were already using a CS so that's fine.

@sbechet This PR needs to be synced against master, other PRs have landed in the mean time and this crate seems to build fine on nightly now. If this is still needed, please explain why and what it does.

[sbechet]

not sure how to rebase cleanly to clean history. Must i rebase then force remote push on my own repository ?

[sbechet]

Hello Jonas and Daniel,

I think it's ok now.

• synced against master
• cleaned history

[MathiasKoch]

Any progress on this?

[jonas-schievink]

r=me with rebase

[sbechet]

done again
ping @jonas-schievink

[jonas-schievink]

This is failing in CI, and it seems like you've included some commits that are on master already

[sbechet]

I don't know what is the best solution between this one and that of bugadani. Like you want.

[jonas-schievink]

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push

[bugadani]

I admit, this is much nicer on the code level than #33. However, since RefCell is not thread safe, and incurs a runtime penalty, I'm not sure if merging this was the right move on the long run. But that's just my 0.02$, I'm glad the crate compiles anyway :)

[jonas-schievink]

Mutex makes it thread-safe, but you're right about the runtime overhead.

Since having an allocator incurs overhead anyways and implies that you have plenty of RAM and can spare the cycles, I think adding another byte of overhead is fine here (and I don't really want to deal with more unsafety than necessary).

[bugadani]

Mutex makes it thread-safe

I'm not here to start an argument, but there's a note in bare-metal which disagrees. /// **This Mutex is only safe on single-core systems.**

[jonas-schievink]

Ah, that is outdated due to RFC 419

[bugadani]

I see. Thank you :)