Is setting to false still needed after stopping everything?

Probably not. I just included it because it felt complete.

The reason I'm asking is because when looking at the following code in HandleTaskStateChanged, I was wondering maybe this code is possible to run even after StopAll(). It might be better to remove this line, but it's up to you :)

                    if (!_stopping)
                    {
                        // StopAll disposes tasks.
                        task.Dispose();
                    }

The stop is done synchronously, so I am more worried about tasks that complete before the stop command that might not get disposed. I have done quite a bit of adhoc testing with abrupt stops so I am inclined to will leave things as-is unless there is a compelling reason to change :). But I really appreciate your input!

I'm curious why this copy is needed. It's a reference copy, right? So both tasksToStop and _taskPool will pointing to the same set of PSTaskBase objects.

Yes, but _taskPool dictionary is modified when a task is disposed. Also the task must be disposed outside the _syncObject lock to avoid a deadlock. To solve these two problems I create a temporary local copy and use that to dispose the final list of runspaces.

Got it. So is there a possibility that new task get added to _taskPool after the copy is done? In that case, the new task will not be disposed, but I guess it will be handled elsewhere?

I don't like to use the word 'impossible' with multi-threading, but it should not be possible to add anymore tasks since the pool is closed and adding tasks is done on a single thread.

Do we want to try dequeue again in case the runspace is broken?

I feel it is better to replace a broken runspace. The task pool will ensure maximum number of threads/runspaces are used.

• When the pipeline objects are not coming in very fast and the parallel script block takes a small time to finish, it's likely there is no need to replace the broken runspace -- rest of the available runspaces can handle all incoming tasks.
• When tasks are coming in fast, the broken runspace will be replaced when all available runspace are used up.

So it's possible that dequeuing again until the queue is empty can have better performance. But I guess the chance of having a broken runspace in the queue is low, so the difference won't be noticeable.

I understand. But this is a tail off scenario. Another strategy is steady state, maintaining maximum pool tasks. But I agree that a broken runspace is unlikely (except for a pathological script which would probably crash the process anyway). At this point I would like to see actual perf scenarios (such as the great work precipitating this change) before making more changes. I have been thinking about pooling threads as well, but there are problems with that and it is not clear what perf improvement would result.