Bug: local_offset_at always fail on MacOS aarch64

[Sytten]

Hi!
This is a follow up to #493. With what I know of the function local_offset_at, it does seems like the library is either unable to count the number of threads or that the count is always more than one for some reason.
I don't think the fix is particularly obvious (for reasons discussed in #493), but I wanted to document it (and I think a whole section on the limitations of local_offset_at should be eventually added to the book).
Thanks

[jhpratt]

Can you please provide the context in which the method is called? The num_threads crate is what determines the number of threads currently running. This is maintained by myself and @Freaky. My suspicion is that the num_threads crate is correct and that there are actually multiple threads running for whatever reason.

[Sytten]

I don't have a device to check, so hard to tell. But considering it is exactly the same code runs well under all other platforms (linux, linux armv7, macos x86, windows) I have pretty sure there is something fishy either in the thread count or maybe the libc call after. But it is consistent.

This is the function I am calling:

fn initialize_logger(debug: bool) -> Result<()> {
    let level = if debug { LevelFilter::Debug } else { LevelFilter::Info };
    SimpleLogger::init(
        level,
        ConfigBuilder::new()
            .set_time_offset_to_local()
            .map_err(|_| anyhow::anyhow!("Unable to set logger local time"))?
            .build(),
    )
    .context("Failed setting up logger")?;
}

I call it like right when main starts so there should only be one thread at this point, before the rest of the application is launched. We do use the blocking crate (https://docs.rs/blocking/latest/blocking/) and I believe actix has a static thread pool too, but they should be lazily started and since it works on all other platforms it seems unlikely that this is the problem.

I have since changed this code anyway to use our internal implementation for timezone fetching so for me it's not an issue anymore, but I wanted to disclose it if other people are having this issue. I think the local_offset_at should document the limitation on single thread.

[jhpratt]

How is main initiated? Are you using an attribute on it to simulate async fn main? There is still insufficient information for me to even begin looking into anything, as I can't rule out that there are actually multiple threads running. If possible, please call dbg!(num_threads::num_threads()) immediately before you're calling local_offset_at. This is what is being called internally.

I think the local_offset_at should document the limitation on single thread.

That would imply it's guaranteed behavior, which it's not. If/when the bug is fixed upstream in the standard library, the restriction will be removed.

[Sytten]

No the main is not async at this point. Though it is possible multiple threads are running even if unlikely considering other platforms work as excepted. I honestly dont think its fixable without having a recent mac which I dont own.

It is unlikely to be resolved anytime soon and many systems will take years before they get a patch. I think leaving off the documentation causes more harm than changing it later since no programmer would guess the current behaviour, but your call.

Feel free to close the issue if you dont think its actionable. Like I said I moved to using tz-rs + tzdb which have been reliable so far.

[jhpratt]

The issue being solved amounts to std::env::set_var being marked as deprecated safe, which is not that far away. That's the only location of unsoundness, ultimately. Nothing on the system level is involved.

The current behavior is not documented because it isn't guaranteed. The user should always be prepared for an error, as that's what the function signature is. This is the case even if this issue didn't exist.

If an issue exists, it would be upstream in the num_threads crate. Closing for that reason and because I am unable to reproduce due to lack of code (even if I had a recent enough Mac).