You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pubfnmax_level() -> LevelFilter{// Since `LevelFilter` is `repr(usize)`,// this transmute is sound if and only if `MAX_LOG_LEVEL_FILTER`// is set to a usize that is a valid discriminant for `LevelFilter`.// Since `MAX_LOG_LEVEL_FILTER` is private, the only time it's set// is by `set_max_level` above, i.e. by casting a `LevelFilter` to `usize`.// So any usize stored in `MAX_LOG_LEVEL_FILTER` is a valid discriminant.unsafe{ mem::transmute(MAX_LOG_LEVEL_FILTER.load(Ordering::Relaxed))}}
AIUI, this means the SeqCst store is not synchronizing with any SeqCst loads, so it is useless. Shouldn't the store also be relaxed (To match what I understand are the current semantics being used), or the load be made SeqCst (To change from the current Relaxed semantics to SeqCst)?
I found this PR which favors using SeqCst everywhere except where it's perf-critical, is the (confusing, and seemingly AFAIK useless since it's not synchronizing with any SeqCst load) SeqCst store intended?
The current load/store pairs seem confusing to me because it's not clear if the semantics desired are Relaxed (In which case the SeqCst store should not be there), or SeqCst (In which case there is currently a bug because of the Relaxed load)
The text was updated successfully, but these errors were encountered:
* Run `$CARGO -vV` in `detect-targets` if env `CARGO` present
* Improve crate doc for `detect-targets`
* Use env var `CARGO` in `install_from_source` if present
* Test use of `CARGO` env in `tests.sh`
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Skimming the code for lib.rs, I see the log level is a global atomic:
I'm opening this issue because, as I understand it, the memory orderings used for the store/loads to this variable in this file make no sense:
SeqCst is used for the store:
Relaxed is used for the load:
AIUI, this means the SeqCst store is not synchronizing with any SeqCst loads, so it is useless. Shouldn't the store also be relaxed (To match what I understand are the current semantics being used), or the load be made SeqCst (To change from the current Relaxed semantics to SeqCst)?
I found this PR which favors using SeqCst everywhere except where it's perf-critical, is the (confusing, and seemingly AFAIK useless since it's not synchronizing with any SeqCst load) SeqCst store intended?
The current load/store pairs seem confusing to me because it's not clear if the semantics desired are Relaxed (In which case the SeqCst store should not be there), or SeqCst (In which case there is currently a bug because of the Relaxed load)
The text was updated successfully, but these errors were encountered: