> We have been testing a change where nesting of DPCs is prevented - > in DispatchDPC we check if we are already processing a dispatch and > exit if we are. (We also modified the dispatch loop to keep looping > until the DPC queues are emptied.) With this approach we still meet > the same-TPL async execution but avoid the whole mess of nesting.
In our testing the proposed approach of avoiding nested DPCs caused other problems, we suspect because there is an expectation in some modules that DPCs are handled immediately on DispatchDpc and deferring them until later violated this assumption resulting in bad behavior. Again it would be really helpful if the DPC design was documented somewhere - the rules, limitations and assumptions are not obvious. So at this point I'm at a loss - changing DPC semantics breaks existing code and TCP4 has structural issues that can corrupt connection state. I hope we can come up with something short of rewriting TCP4 that can resolve this. Thanks, Eugene _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
