Explain how come this library is faster than built-ins

[xixixao]

The README already describes "why" in terms of the approach this crate takes. What I'm missing is a short explanation of why the standard Rust library takes a different approach. In other words, the README reads like a lot of "pro"s, what I'm curious about are the "con"s in the trade-off I'm making when using this crate over the built-ins.

There should be some cons or else I'd expect this library to replace what's currently in the standard library, unless the standard library is stuck for legacy reasons (which could be the explanation I'm looking for).

Hope you will find this helpful.

[faern]

There has been effort put into merging parking_lot into the standard library indeed. But it was problematic for a number of reasons. One was platform support. The standard library locking primitives could be used on a number of more exotic platforms where parking_lot could not. Most of that was resolved in the effort to upstream it.

Another reason blocking it was the "code quality". More specifically the library team commented on parking_lot lacking enough code documentation, a bit too much unsafe that was not properly documented and a number of memory orderings they felt would be better to lean towards the more safe SeqCst. You can read a pretty extensive review of this library in the context of getting it into std here: faern#1

In summary. There are no real known cons of using parking_lot. But its correctness has also not been proven enough to be accepted into std.