Closed uncomputable closed 9 months ago
thread_local
is more efficient than Once
because it doesn't need to use synchronization every time that it's accessed.
If WASM can't handle thread_local
, even though I wrote the original code specifically with WASM in mind (in which it should be a no-op because WASM has no threads), then I guess it's fine to hack around it by making our code less efficient and unsafe. But I'm not thrilled about it.
I can't test this until we update the vendored version of Simplicity for the recent CI fixes.
Actually, no, I was just building from the wrong system and had an outdated check-pr.nix. I think this is working now.
For now, I reordered the commits to make the tests work.
thread_local!
works, so I added it back in. The borrow error no longer occurs.
We could share the same powers of two across threads using RwLock
or OnceLock
, but this requires MSRV 1.63.0 and MSRV 1.70.0, respectively, to work in const
, so this is for later.
RwLock
is extremely slow and should basically never be used unless your problem architecture really requires it. Not sure about OnceLock
. It's likely to be better.
Fixes issues that came up while parsing the human encoding in WASM.