search

hawkw / sharded-slab

a lock-free concurrent slab (experimental)
MIT License
269 stars 17 forks source link

Swap out lazy_static for once_cell #72

Open james7132 opened 2 years ago

james7132 commented 2 years ago

Fixes #71. Another benefit is that accessing registry's next counter doesn't require an extra lazy check, only on the actual freelist.

hawkw commented 2 years ago

It looks like CI is stuck on this PR --- not totally sure what's going on there.

james7132 commented 2 years ago

Should we report this to GitHub? This seems like it's permanently stuck.

hawkw commented 2 years ago

Looks like that was my fault; I changed the CI configuration, and it should run correctly now.

jplatte commented 2 years ago

@james7132 are you still intending to finish this (fix the two CI failures)?

james7132 commented 1 year ago

Looks like once_cell uses the 2021 edition, which has a MSRV of 1.56. Is this acceptable to bump the MSRV of this crate? or should I instead pin an earlier one that is compatible with this crate's MSRV of 1.42?

james7132 commented 1 year ago

@hawkw ping about this question

jplatte commented 1 year ago

@james7132 maybe just update the PR to get it to go green, since this would be a trivial change? Then there's a chance no further back and forth is needed when Eliza finds some time for this again.

james7132 commented 1 year ago

With syn 2.0.0 coming out bumping it's MSRV to 1.56, there's likely a bunch of crates bumping their MSRVs soon. Went ahead and updated the MSRV, added a rust_version field to Cargo.toml, and updated the CI workflow.

james7132 commented 1 year ago

Also bumped the edition to 2021.

james7132 commented 1 year ago

Loom seems to dislike once_cell's Lazy implementation. It's apparently unsupported right now, see https://github.com/tokio-rs/loom/issues/263.

james7132 commented 1 year ago

Seems like parts of once_cell have been stabilized into std: https://github.com/rust-lang/rust/pull/105587.

raftario commented 1 year ago

Now that OnceLock is stable another possibility would be to use it instead but keep lazy_static as an optional feature for older compiler support

Expyron commented 10 months ago

Although you probably don't want to increase the MSRV that much for now, VecDeque::new() was made const in 1.68, so it'll be possible to remove lazy_static/once_cell usage altogether at some point.

notgull commented 10 months ago

Any progress on this PR? I'm trying to purge lazy_static from my dependency tree.

jplatte commented 10 months ago

Now that OnceLock is stable another possibility would be to use it instead but keep lazy_static as an optional feature for older compiler support

This would be nice. Could be a default Cargo feature msrvXXXX that you can disable to get a lighter dependency tree at the expense of requiring a newer compiler.