@xiang.zhang: Your patch looks to be introducing a number of changes to the structure of the data being passed around between threads and even monitored/indirectly shared across processes.  It's looking increasingly high risk to me.

We already have logic for handling exceptions arising during jobs but the one situation overlooked in this logic is if the exception occurs "quickly in an unfortunate order", meaning the exception is encountered and reported before any of the other individual tasks can complete and respond with a result.  This oversight of logic can be addressed a couple of ways:
1.  Add a flag to our IMapIterator to indicate when any exception is encountered.
2.  Modify the tuples / data structures being maintained across IMapIterator's _cache, _items, _unsorted, _index, and _length.
3.  Under relevant conditions, check both _items and _unsorted (not only _items) before declaring that we truly have all results in.

I regard option 1 as being potentially a bit fragile and option 2 as introducing non-trivial complexity and risk.  With option 3, there's effectively no risk and no measurable cost getting to the truth of what has actually happened.