1999 motivates the need for a general PIFO. It also discusses a made-up strategy for implementing such a PIFO. It leaves on the table, however, another straightforward solution: binary heaps.
This is a tracker for the things we need.
[x] A module that accepts values and pushes them into a min-heap ordered by value. Done via #2074
[x] Tweak the above to accept a value and a rank, and push a (value, rank) tuple ordered by rank. Done via #2145
[x] Modify the above to obey the queue interface. It won't be possible to obey the interface exactly, since the binary heap will need ranks as well as values, but maybe get it close. Done via #2145
[x] Add peek and pop functionality. Done via #2145
[x] Test! Done via #2174
[x] Document! Done via #2182
[x] Write logic for a scheduling transaction that interacts with the above, granting ranks to values. The scheduling transaction + binary heap combination will be able to obey the queue interface exactly.
[x] A basic first goal for this would be a scheduling transaction that achieves fairness among the incoming classes of traffic; if we can do this then the scheduling transaction + binary heap would become a drop-in replacement for our super limited PIFO that can only do fairness.
Done via #2174
[x] More generally, there is lots of room to run here. Other scheduling transactions can achieve other goals, and our super limited PIFO will not be able to match this behavior. Sorta the point of a truly general PIFO. See this glossary for inspiration. It would be super if we had a little zoo of policies like this!
Done via #2174
1999 motivates the need for a general PIFO. It also discusses a made-up strategy for implementing such a PIFO. It leaves on the table, however, another straightforward solution: binary heaps.
This is a tracker for the things we need.
push
es them into a min-heap ordered by value. Done via #2074push
a (value, rank) tuple ordered by rank. Done via #2145peek
andpop
functionality. Done via #2145