Instead of using a simple switch to determine if preemption is enabled
(`is_preemptable: bool`), a counter is used instead. This handles the
case where a function holding a `PreemptGuard` calls another function
that creates a new `PreemptGuard`.
Signed-off-by: Anhad Singh <andypython@protonmail.com>
This is not a perfect solution, since the kernel technically already has
all the information it needs to synchronize this between the kill()
invocation and the time WaitCondition::wait is called, but it should not
have any noticeable performance impact.
The spin crate considers it UB to call force_write_unlock while there is
a threads trying to obtain a read lock on the same rwlock.
This also switches to the spinning_lot crate for the context rwlock as
it has support for a write guard keeping a reference to the rwlock using
an Arc instead of a reference.
Most of this was generated by the absolutely extraordinary `cargo fix`
subcommand. There were still 2 errors and a few warnings to patch up,
but compared to the normal 600+ errors, I'd say the fixer did a damn
good job! I'm also amazed that I could still start the VM after this,
I half expected some kinds of runtime failure...
Wildan M