Event handler hit many times rapidly seems to "short-circuit"

Question

I have an event that is raised from a third-party library, which executes on a background thread. This event basically notifies listeners of status updates in the system the library is watching. The handler invokes itself on the UI thread if InvokeRequired is true, and in either case then proceeds to append an entry for the status change to text in a textbox, and pop up a notification in the tray.

Now, the problem is that these status updates can come in very rapidly; the system being monitored can go from its "idle" state through several intermediates to a "ready" state in milliseconds. I need to know that the system has transitioned through all of these intermediate states; however, not all of the state changes are getting to the log. Setting a breakpoint and stepping through the handler shows the oddest behavior; the handler will step through the first couple of lines of code, and will then jump back to the method's entry. It's almost as if either the event or the Windows message pump is aborting the method call because another call to the same method is incoming. Putting the method body in a lock block does not solve it.

I've seen this before in other projects that do not use this third-party library. I wasn't as concerned there, because the rapid-fire event was simply triggering window redraws. If they all happened, great, but if one was short-circuited, there was another in the pipe that would go through. This, however, is a much more application-critical task that must happen every time the event is raised, in order (it doesn't have to happen as fast as the states actually change; definitely not expecting that).

What's the cause of this short-circuiting behavior, and how do I stop it?

Answer 1

Rather than doing all of the work synchronously in the thread the event handler fires in it would likely be beneficial to do the work in another thread.

Just wrap everything you're doing in your current event handler in a Task.Factory.StartNew, or use BeginInvoke to marshal to the UI thread instead of Invoke.

I couldn't be sure as I have no knowledge of that library, but it could be that it's unable to fire more events until it finishes executing all of the event handlers for the previous event.

Another option that you may need to do, either to solve this problem, or to prevent your UI from being mad at you for so many updates, is to take the status changes as the come in and just dump them into a collection, and then just periodically check that collection and process all of the changes in a batch. This would be easier on the event handler for the 3rd party object as it just needs to add an item to a collection, and also easier on the UI as it won't need to update several times in the span of time the monitor can even render the changes.

Answer 2

What you're seeing is most likely new calls to the event handler from the background thread while the call you first started stepping through is still running.