spin-rs no longer maintained (dependency)

[bluejekyll]

https://rustsec.org/advisories/RUSTSEC-2019-0031

The spin dependency is no longer maintained it appears. This causes cargo audit to fail on downstream projects. I haven't had a chance to look into potential fixes.

[briansmith]

Thanks. I don't think the spinlock design in spin-rs was optimal for what we were using it for anyway. In particular, we really just need a pure spin lock that doesn't ever yield.

[briansmith]

In fact, we don't even need a spinlock, really. We just use spin::Once and so we just need a variant of that that is no_std compatible, that is as optimistic as possible that the initialization has already been done.

In particular, we really just need a pure spin lock that doesn't ever yield.

Actually, I just checked my notes and we intentionally don't use a pure spinlock to gracefully handle very edgy edge cases, e.g. the process that grabbed the lock has been suspended while (or just before) the handful of instructions that cache the CPUID results. IIRC, spin-rs was way too eager to yield, but never yielding also isn't right.

[briansmith]

I wrote:

we just need a variant of that that is no_std compatible, that is as optimistic as possible that the initialization has already been done.

IIRC, spin-rs was way too eager to yield, but never yielding also isn't right.

If we really want to be optimistic that the initialization has already been done, then spin-rs's behavior of yielding right away makes a lot of sense, actually. So, I think we should just find the simplest thing that will work.

[bluejekyll]

If we were happen with the Once in spin-rs perhaps we should just fork that and maybe add it to the lock-api project (referenced in the CVE).

[briansmith]

If we were happen with the Once in spin-rs perhaps we should just fork that and maybe add it to the lock-api project (referenced in the CVE).

Perhaps. I see lock_api depends on scopeguard only (its other depencencies are optional, it seems).

In general the problem I'm running into now is finding an alternative that doesn't have heavy dependencies. (It looks like rust-lang/rust#56410 and similar long-stalled work has had a chilling effect on development of projects solving these problems.)

[briansmith]

I filled rust-lang-nursery/lazy-static.rs#163 against lazy-static.

[briansmith]

I put up PR #924 to see if switching to conquer-once would work (pass CI). If so, we could consider switching to that after reviewing the code.

There are two parts to this: cpu.rs and rand.rs.

In cpu.rs, we need to support no_std environments and thus we need a direct replacement to spin-rs, which conquer-once does provide. Notable, the Rust RFC for standardizing a replacement for lazy-static at rust-lang/rfcs#2788 as currently drafted does NOT propose to create something that we could use for cpu.rs.

In rand.rs, we could use once_cell and the variant that is proposed in the RFC mentioned in the previous paragraph.

It would be interesting to know what @oliver-giersch is planning to do with conquer-once if/when the aforementioned RFC is mentioned. I would hope that conquer-once would shrink in scope. But maybe conquer-once does more than the RFC proposed that I'm overlooking.

[oliver-giersch]

It would be interesting to know what @oliver-giersch is planning to do with conquer-once if/when the aforementioned RFC is mentioned. I would hope that conquer-once would shrink in scope. But maybe conquer-once does more than the RFC proposed that I'm overlooking.

I primarily intended for conquer-once to be no-std compatible in a way that plays well with the commonly accepted way of structuring cargo features to enable no-std compatibility (which lazy_static does not) and also allow mixing std and no-std crates using conquer-once in the same dependency graph without forcing all of them to use the same blocking strategy (by using separate types for spin-locks and the OS reliant blocking strategy).
Secondly I set out to provide a non-blocking API in addition to the more common blocking one, although this may have been somewhat misguided, but with all the recent async hype it may turn out to be useful to someone someday.

What exactly do you find too extensive about the crate's scope?

[briansmith]

Thanks for commenting.

What exactly do you find too extensive about the crate's scope?

As things are now, nothing! But, if/when the lazy_static functionality is in libstd, would that change what conquer-once does or how it works? For example, if libstd were available, it might be nice for conquer-once to defer to the libstd implementation.

[oliver-giersch]

Thanks for commenting.

What exactly do you find too extensive about the crate's scope?

As things are now, nothing! But, if/when the lazy_static functionality is in libstd, would that change what conquer-once does or how it works? For example, if libstd were available, it might be nice for conquer-once to defer to the libstd implementation.

I might reassess whether the additional non-blocking capabilities are worth maintaining further. But as it is now, the part of the crate that would overlap with the proposed RFC (the OS reliant blocking API) is only compiled if the std feature is enabled, so I might also just downgrade that from a default feature to a purely optional one.
BTW, your comment has prompted me to finally publish version 0.2.0 which contains some soundness fixes as well as some breaking API changes.