0

I have a BackGroundWorker that pends on a WinUSB ReadPipe() call in DoWork(). When ReadPipe() returns data, that data is packaged into the DoWorkEventArgs parameter and DoWork() ends.

Usually RunWorkerCompleted() executes very soon after DoWork() ends. Every now and then, however, there is a 5 second delay between the two. I used DateTime.Now timestamps at the start and end of DoWork() and RunWorkerCompleted(), to determine exactly where the delay occurs.

What could be causing the delay between DoWork() and RunWorkerCompleted()? Is it anything that I can do something about?

BigBobby
  • 423
  • 1
  • 3
  • 17
  • 1
    Are you blocking your main thread during that time? This is the most likely explanation. – J... Jul 09 '14 at 13:38
  • 1
    If you post the relevant parts of your code, folks might be able to help you spot the problem. – Grim Jul 09 '14 at 13:39
  • There's no magic here. `RunWorkerCompleted` has to wait it's turn before the OS can run it's thread. If it's busy doing other stuff it might wait a while. If the `BackGroundWorker` was started on the UI thread, then `RunWorkerCompleted` should run on that thread too and if that thread is busy, it'll have to wait. You can't expect `RunWorkerCompleted` to run immediately and should plan accordingly. – Matt Burland Jul 09 '14 at 13:42
  • 1
    @Grim If he's blocking the main thread then the relevant part of the code could be anything. Any method in the application that runs on the main thread could be holding up message processing. What OP needs to look for are methods in his application that are taking longer than a few hundred ms to complete. – J... Jul 09 '14 at 13:42
  • As J.. states RunWorkerCompleted() runs on the main thread so it needs to wait its turn. In debug you could see what code is active, the problem you are going to have there is once you slow it down in debug you may not feel the delay. Maybe do an assert on that time difference and if it is greater then X and look at the call stack. – paparazzo Jul 09 '14 at 15:19
  • Thanks for the answers! As you suspected, it was the main program blocking.I should mention that I inherited a medium-sized program that was originally written by an intern. In a function I hadn't ventured into yet, I found a hidden ListBox that was being emptied every now and then with a big For loop in which the oldest 500 strings were removed. While I'm a bit surprised that the 500 element For loop took 5 seconds, I was able to prove that the 5 second delay occurred when DoWork() completed before this loop was entered. I'm just deleting this hidden control to solve the problem. – BigBobby Jul 09 '14 at 15:26
  • BTW - I figured this out by making my own call history list: `Public method_called_list As New List(Of String)' which I think filled at the start of every Sub and Function call with 'System.Reflection.MethodInfo.GetCurrentMethod().ToString()' Is there a simpler way to have done this? – BigBobby Jul 09 '14 at 15:27
  • @user3754356, there are several ways of solving this with minimal code duplication. Look into method invocation interception with dynamic proxies (Castle Project) or aspects (PostSharp). – Kirill Shlenskiy Jul 10 '14 at 12:01

0 Answers0