Implement OnIdle engine events #1581
Conversation
ghost
added
src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs
Outdated
Show resolved
Hide resolved
src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs
Outdated
Show resolved
Hide resolved
src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs
Outdated
Show resolved
Hide resolved
| // We didn't end up executinng anything in the background, | ||
| // so we need to run a small artificial pipeline instead | ||
| // to force event processing | ||
| if (runPipelineForEventProcessing) |
There was a problem hiding this comment.
I think it'd be worth explaining why, architecturally, we have to do this.
There was a problem hiding this comment.
I got it from here, but @daxian-dbw might know more
| @@ -36,7 +36,7 @@ public BlockingConcurrentDeque() | |||
| }; | |||
| } | |||
|
|
|||
| public int Count => _queues[0].Count + _queues[1].Count; | |||
| public bool IsEmpty => _queues[0].Count == 0 && _queues[1].Count == 0; | |||
There was a problem hiding this comment.
FYI BlockingCollection has no IsEmpty property
There was a problem hiding this comment.
Technically there may be a race here, no?
There was a problem hiding this comment.
If any method in BlockingCollection is executing while the Count property is being accessed, the return value is approximate. Count may reflect a number that is either greater than or less than the actual number of items in the BlockingCollection.
Yup. Do we want to lock around this somehow?
There was a problem hiding this comment.
No I don't think it's worth it; we only want an approximation ourselves, and there's no point in us trying to make a hard answer out of two soft values.
There was a problem hiding this comment.
The scenario I'm thinking of is where we choose to end the iteration across the items of the pipeline. There's a race between checking that the pipeline is empty and ending the iteration: a task could get queued in-between and then it would be lost, no?
There was a problem hiding this comment.
I guess the answer is going to come from the question: would it be lost, or would it simply be delayed until something else iterates over it?
There was a problem hiding this comment.
a task could get queued in-between and then it would be lost, no?
No, the task wouldn't be lost; we don't modify the queue if we think it's empty.
We make a decision about whether to process the queue early on based on whether there's anything in it. If the queue looks empty, nothing is processed. If we're wrong, the only thing that happens is the queued task won't be processed until the next time the queue is serviced, which will mostly be in 300ms.
As you say, if we're wrong, processing is just delayed.
Resolves #1433