updoot
This commit is contained in:
parent
0c766a381b
commit
4af41533d4
1 changed files with 4 additions and 0 deletions
|
|
@ -16,6 +16,10 @@ CPN concurrency can be describe succinctly: if the workloads touch disjoint plac
|
|||
|
||||
# Appendix
|
||||
|
||||
## Reasoning About State Transitions
|
||||
|
||||
Shits hard man. You effectively wander around the potential state space, conjuring potential situations in your head, then trying to figure out the edge cases relative to your current state machines and connecting logic, to figure out if there are any consistency errors possible or gaps in the model. Imagine how hard it would be without state machines! The purpose is to pull bugs related to this forward as much as possible.
|
||||
|
||||
## Partition Collisions?
|
||||
|
||||
Random thought, we also have this lingering "what if unrelated wants collide in the partition space", specifically for a paradigm where job runs produce multiple partitions based on their parameterization. This may also give us the confidence to just cancel the later of the colliding jobs and have it reschedule (how would partitions be diff?). Or, given that we update partition building status on job schedule, we would be confident that we just never get into that situation at the later want grouping stage (pre job scheduling), it would see the conflict partition as building thanks to the earlier job being started. Probably worth constructing a literal situation for this to war game it or implement a literal integration test.
|
||||
|
|
|
|||
Loading…
Reference in a new issue