Tracking issue for Scheduler-Level Resource Sharing (SLRS)

[kennystrawnmusic]

An important design goal I've had for a while related to this kernel is a better way to manage CPU resources at the scheduler level, thus taking the burden of needing to build multithreaded apps in order to take advantage of multiple cores off of the developer. That's where the wake_ipi interrupt handler has become an all-important tool.

By telling the handler to first execute the instruction that the program counter points to and then go on to send the very interrupt that it handles to the next available core — such that all the CPU cores are passing the instruction pointer around to each other in a loop using the IPI as a means to that end — it's possible to preemptively schedule each instruction individually while bouncing from core to core. This makes it so that even single-threaded apps have all that power readily available to them.

Things to be ironed out:

• Order in which the tasks are performed: don't know whether to mutate the ACTIVE_LAPIC_ID before executing the instruction stored by the IP or after update: definitely after; modifying the atomics can cause straight-up UB otherwise
• Performance: currently uses an AtomicU32 to track each Local APIC ID as the instruction scheduler rounds the robin; might be the only way to go about this but hopefully there's a workaround that is less resource-intensive. Not the best solution but using Ordering::Relaxed is less resource-intensive than Ordering::SeqCst. Also, managed to cut the signature of the handler a bit by using Iterator::cycle() which I didn't know existed.
• The need to use .as_ptr::<fn() -> ()> to lie to Rust that the instruction pointer is a function pointer (when in fact it isn't) in order to execute the instruction that it points to. There has to be a better way than that; if someone from the Rust team (or from @rust-osdev) has insight into this it would be greatly appreciated.