Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You shouldn't have to worry about Send and Sync if you aren't using generic types that require that their type parameters be Send and Sync. What such types are you using?


Various no_std libs use Send+Sync in places which makes things fun.

Another would be static mutable variables, which are perfectly safe in a single-threaded environment, doubly so if you map that memory on a per-core basis to ensure each kernel has a unique variable value. Esp if you need lazy_static then there aren't many options other than wrapping the data in a mutex for no good reason.


If it's per-core you should look into making `#[thread_local]` statics work, which remove some of the restrictions.

`static mut` is not always safe even in a single-threaded environment, because of reentrance - see also https://github.com/rust-lang/rust/issues/53639.


I'm not sure if Thread local would work since i'm not certain if the bootloader can handle a TLS section in the ELF file, my kernel cannot do this either as I've yet to implement threading.

Reentrance is not the issue here, I guard this inside the data structure, interrupts will be worst case reentrance most of the time.


Then you can use the techniques in the thread I linked.

But without guarding mutability behind some way to indicate interrupts are disabled, or an outright lock, and without guaranteeing no data races (Sync), it's not actually safe.

And the compiler can't make `static mut` safe to use as any of those requirements could be broken and then it's not safe at all anymore.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: