Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibly remove a lot of lazy_static #1132

Open
hecatia-elegua opened this issue Aug 21, 2022 · 9 comments
Open

Possibly remove a lot of lazy_static #1132

hecatia-elegua opened this issue Aug 21, 2022 · 9 comments

Comments

@hecatia-elegua
Copy link
Contributor

hecatia-elegua commented Aug 21, 2022

as 1.63.0 enables const mutex:
https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html#const-mutex-rwlock-condvar-initialization
edit:
and spin already has support for this anyways :)

@bjorn3
Copy link
Contributor

bjorn3 commented Aug 21, 2022

Blog os doesn't use std mutexes, so this change doesn't affect blog os in any way. The spin crate which provides the Mutex blog os uses already had support for this. Some cases could already have been rewritten to not use lazy_static, but in other cases the value to put in the mutex can't be constructed using const.

@HKalbasi
Copy link
Contributor

Should we rewrite the remaining one to use Lazy from once_cell? It seems there is a consensus in ecosystem to move away from lazy_static! since it is going to be in standard library and works better with rustfmt and rustdoc. Since this blog is an educational content, I think it is better to use once_cell so that people can get to know once_cell from the beginning instead of learn lazy_static and then drop it and learn once_cell. @phil-opp if you would accept a PR for this, I can write it.

@bjorn3
Copy link
Contributor

bjorn3 commented Sep 23, 2022

once_cell depends on libstd for locking, unlike lazy_static which works with spin locks too.

@HKalbasi
Copy link
Contributor

With matklad/once_cell#195 being merged, is it now possible to replace lazy_static?

@bjorn3
Copy link
Contributor

bjorn3 commented Oct 22, 2022

critical_section (used by once_cell for no_std) requires you to inplement a trait and then set it as global impl. spin (used by lazy_static for no_std) on the other hand just works without needing any configuration.

@HKalbasi
Copy link
Contributor

IMO it is not a problem. It adds something to learn, and solves a valid problem: using a lazy_static value inside and outside of an interrupt handler can cause a deadlock, critical section can solve that by disabling interrupts before spin-locking. And we can go even further and use a critical section based mutex, which eliminate the need for disabling interrupts manually.

@hecatia-elegua
Copy link
Contributor Author

@bjorn3 having seen you in many places around the rust ecosystem, I would like to thank you for all the information you're giving even on rather small issues like this. I'm always learning some new things from it.

@zefr0x
Copy link

zefr0x commented Jan 28, 2024

once_cell depends on libstd for locking, unlike lazy_static which works with spin locks too.

critical_section (used by once_cell for no_std) requires you to inplement a trait and then set it as global impl. spin (used by lazy_static for no_std) on the other hand just works without needing any configuration.

generic_once_cell could be used. (bring your own mutex)

use generic_once_cell::Lazy;
use spin::Mutex;
use uart_16550::SerialPort;

pub static SERIAL0: Lazy<Mutex<()>, Mutex<SerialPort>> = Lazy::new(|| {
    let mut serial_port = unsafe { SerialPort::new(0x3F8) };
    serial_port.init();

    Mutex::new(serial_port)
});

@zefr0x
Copy link

zefr0x commented Feb 12, 2024

I found an implementation for this directly in the spin library since 0.7.0 as spin::lazy::Lazy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants