You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add kani::spawn and an executor to the Kani library (rust-lang#1659)
This adds an executor (scheduler for async futures) to the Kani library, thus supporting `kani::spawn` as a replacement for `tokio::spawn`.
It also includes `kani::yield_now` which is similar to `tokio::yield_now`.
Co-authored-by: Celina G. Val <[email protected]>
/// Indicates to the scheduler whether it can `kani::assume` that the returned task is running.
54
+
///
55
+
/// This is useful if the task was picked nondeterministically using `kani::any()`.
56
+
/// For more information, see [`SchedulingStrategy`].
57
+
pubenumSchedulingAssumption{
58
+
CanAssumeRunning,
59
+
CannotAssumeRunning,
60
+
}
61
+
62
+
/// Trait that determines the possible sequence of tasks scheduling for a harness.
63
+
///
64
+
/// If your harness spawns several tasks, Kani's scheduler has to decide in what order to poll them.
65
+
/// This order may depend on the needs of your verification goal.
66
+
/// For example, you sometimes may wish to verify all possible schedulings, i.e. a nondeterministic scheduling strategy.
67
+
///
68
+
/// Nondeterministic scheduling strategies can be very slow to verify because they require Kani to check a large number of permutations of tasks.
69
+
/// So if you want to verify a harness that uses `spawn`, but don't care about concurrency issues, you can simply use a deterministic scheduling strategy,
70
+
/// such as [`RoundRobin`], which polls each task in turn.
71
+
///
72
+
/// Finally, you have the option of providing your own scheduling strategy by implementing this trait.
73
+
/// This can be useful, for example, if you want to verify that things work correctly for a very specific task ordering.
74
+
pubtraitSchedulingStrategy{
75
+
/// Picks the next task to be scheduled whenever the scheduler needs to pick a task to run next, and whether it can be assumed that the picked task is still running
76
+
///
77
+
/// Tasks are numbered `0..num_tasks`.
78
+
/// For example, if pick_task(4) returns (2, CanAssumeRunning) than it picked the task with index 2 and allows Kani to `assume` that this task is still running.
79
+
/// This is useful if the task is chosen nondeterministicall (`kani::any()`) and allows the verifier to discard useless execution branches (such as polling a completed task again).
80
+
///
81
+
/// As a rule of thumb:
82
+
/// if the scheduling strategy picks the next task nondeterministically (using `kani::any()`), return CanAssumeRunning, otherwise CannotAssumeRunning.
83
+
/// When returning `CanAssumeRunning`, the scheduler will then assume that the picked task is still running, which cuts off "useless" paths where a completed task is polled again.
84
+
/// It is even necessary to make things terminate if nondeterminism is involved:
85
+
/// if we pick the task nondeterministically, and don't have the restriction to still running tasks, we could poll the same task over and over again.
86
+
///
87
+
/// However, for most deterministic scheduling strategies, e.g. the round robin scheduling strategy, assuming that the picked task is still running is generally not possible
88
+
/// because if that task has ended, we are saying assume(false) and the verification effectively stops (which is undesirable, of course).
89
+
/// In such cases, return `CannotAssumeRunning` instead.
0 commit comments