The new update driver is not yet taking advantage of the "likelyInPhysicalMemory" heuristic and thus it may go on to page in with the lock held.
The tricky part here is that bubbling up a negative return for likelyInPhysicalMemory in the old code is done through an exception. A page not being in memory is a perfectly fine situation, though.
Once the new framework is swapped in (and probably as adjusting instance.cpp:receivedUpdate), the driver may use a status to report that scenario.
- related to
-
SERVER-10301 Add support for yielding on non-atomic updates to new update framework
- Closed