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

without_interrupts(): Restore previous interrupt state rather than always re-enabling interrupts #10

Open
dylanmckay opened this issue Nov 5, 2018 · 3 comments

Comments

@dylanmckay
Copy link
Member

dylanmckay commented Nov 5, 2018

The without_interrupts() in PR #4 always enables interrupts when the closure finishes executing.

This could be problematic in libraries; a library using this function assumes that the program it is included in actually wants interrupts to be disabled, or even if interrupts were already disabled before the call to without_interrupts

We should make a copy of the the interrupt flag in the status register, and then restore the interrupt flag back to its previous state, not just re-enabled it.

@shepmaster
Copy link
Member

shepmaster commented Nov 5, 2018

store the interrupt flag in the status register

One thing that I think would be very interesting to explore would be to see if we could track the state of the interrupt flag via compile-time information. For example:

// This trait is not correct, but shows a general sketch of how it might look.

trait InterruptState {
    fn with_interrupts<R>(self, f: impl FnOnce() -> R) -> R;
    fn without_interrupts<R>(self, f: impl FnOnce() -> R) -> R;
}

struct InterruptsDisabled;

impl InterruptState for InterruptsDisabled {
    fn with_interrupts<R>(self, f: impl FnOnce() -> R) -> R {
        // set register
        let x = f();
        // unset register
        x
    }
    
    fn without_interrupts<R>(self, f: impl FnOnce() -> R) -> R{
        f()
    }
}

struct InterruptsEnabled;
// ditto

struct InterruptsUnknown;
// ditto

When we don't know the state, we use InterruptsUnknown which gets the current state. A obsessive program could thread this through everywhere, since IIRC we start the machine with interrupts in a known state.

@dylanmckay
Copy link
Member Author

I think that's a good idea

@stappersg
Copy link
Member

linking with #44

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

No branches or pull requests

3 participants