After injecting functions from the system.js collection to the global scope of the JavaScript context, map-reduce acquires a lock on the database in MODE_S. Every 100 times the plan executor is ADVANCED, the operation context is checked to see if it has been interrupted. If the mapper function takes a long time to execute, then operations that acquire a lock on the database in MODE_X or MODE_IX will block behind the JavaScript execution. However, it seems undesirable to execute potentially long-running JavaScript (e.g. the mapper or reducer) if the map-reduce operation was interrupted in Scope::loadStored().
Some of the test cases in mr_killop.js use non-terminating mapper and reducer functions. This has been the source of build failures when running mr_killop.js as part of the parallel suite (i.e. jstests/parallel/basic.js and jstests/parallel/basicPlus.js) because the killOp() occurs while loading the stored functions.
I have only been able to reproduce this issue when running with SpiderMonkey (default JavaScript engine since 3.1.7+), but I'm not familiar enough with the V8 integration to know for certain that it isn't also affected.