If killCursor is called on the cursor, it is marked as "killPending", and later reaped by the periodic ClusterCleanupCursorJob.

"Reaping" the ClusterClientCursor sends killCursors to all shards that have cursors on them as part of this sharded query.

Currently, only one thread can use a ClusterClientCursor at a time, because the cursor must be "checked out" of the ClusterCursorManager to be used. This means if killCursor is called on the cursor while the cursor in use by a thread, the cursor is not killed by the reap thread until the first thread has finished getting a round of results from it and checked it back in.

It would be preferable if it was possible to "interrupt" the ClusterClientCursor from the reap thread, by interrupting the operation which is using the cursor's operation context.

This would mean the first thread would stop scheduling further requests to get results, and just wait for outstanding responses to return. This is much better than waiting for the entire round of results to complete.

Currently, the AsyncResultsMerger (ARM) kind of supports being killed from a second thread: on ARM::kill(), it stops scheduling further requests as described above. However, if the thread doing kill() destroys the ClusterClientCursor after kill() returns, the first thread will have a reference to (and perhaps try to use) an invalid ClusterClientCursor, including an invalid ARM.

The work in SERVER-27937, which splits the ClusterClientCursor's implementation into a CursorEstablisher and ARM, will mean the first thread may have a reference to an invalid CursorEstablisher or invalid ARM.

kaloian.manassiev