kernel: Check for interrupts and deferred calls

[bradjc]

Pull Request Overview

This pull request changes the do_process loop to break (and stop running a process) if either:

• There is a pending interrupt
• There is a pending dynamic deferred call

Before, this only happened on a pending interrupt.

Without this change, applications take priority over pending dynamic deferred calls. This is most noticeable with virtualized uart. If an app calls a syscall that tries to transmit a buffer over uart, the virtual uart mux enqueues a deferred call. That is not an interrupt, so the process loop continues and likely the process may be re-executed. The deferred call will not be executed until the process yields or exhausts its timeslice.

Testing Strategy

I found this on the arty-e21 board which does not have a systick implementation. I tried to use strace, and it didn't display anything. The board turned out to be crashing, so deferred calls were never serviced.

If you want to see this on hail:

1. Modify sched.rs to disable the systick.
2. Enable strace in the kernel.
3. Comment out the debug!() line in main.rs (the UART interrupt from that seems to make things work).
4. Run the whileone app.

The strace printouts won't happen. If you use process console to generate an interrupt then they will get printed.

TODO or Help Wanted

n/a

Documentation Updated

• Updated the relevant files in /docs, or no updates are required.

Formatting

• Ran make formatall.

[lschuermann]

Looks good.

So within my first contribution I already managed to introduce a race condition and missed this one. Wondering what's to come next. 😆

[ppannuto]

bors r+

I think this is good as an immediate fix. It might be nice as part of the scheduler work to expose an understanding of "real" interrupts and "synthetic" interrupts (these) to the scheduler; but we can cross that bridge when we come to it.

[bors]

Build succeeded:

• continuous-integration/travis-ci/push