My straw-man proposal is ready :)

The process_blocks function now accepts an 'executor' class which determines the execution strategy to be followed. I have implemented single-threaded synchronous (FuncExec) as the default as well as a multiprocessing based example (MultiProcExec).

The process_blocks function now returns an instance of the 'executor' class with execution in progress (assuming asynchronous execution). Currently the self._map function for both FuncExec and MultiProcExec blocks until the results are all available, so the current implementation is somewhat contrived, but I will fix that in a next pass. I have also not looked at the problematic overlap parameter implementation.

The FuncExec and MultiProcExec each provide two ways of making the block results available:
1. instance.result() will block until all the block results are available and then returns the combined results in an np.ndarray with block results positioned correctly according to the original block layout.
2. instance.ready() returns a generator that yields results as it becomes available (not necessarily is order). The block index is returned with the result to provide the context of the block result.


    Examples
    --------
    >>> from skimage.data import camera
    >>> from skimage.color import gray2rgb
    >>> image = camera()

    >>> output = process_blocks(image, (8, 8), np.sum)
    >>> output2 = process_windows(gray2rgb(image), (8, 8, 3),
    ...                           np.sum, {'axis': -1}).result()

    >>> output = process_blocks(image, (8, 8), np.sum)
    >>> for index, result in process_windows(gray2rgb(image), (8, 8, 3),
    ...                           np.sum, {'axis': -1}).ready():
    >>>     print index, result


I am not sure if the class based approach is the best, I have noticed that there are no other class definitions in the whole of the scikit.image project.

Please comment.