I’m observing some strange behavior in my code and I’m trying to track down the source. I have two single threaded .net applications running and sending WCF messages to each other on the same machine. They are very simple, there is a blocking write and then a blocking read. I have noticed that on my blocking call in my log, 99.99% of the time I read / write in ~10 ms. However in very rare circumstances, it may take 500-2000 ms. I’m trying to understand exactly why this might be. I have a few odd quirks to my app that I am tracking down and may be the culprit, but I was wondering if this was entering into territory where there’s something about the framework that I don’t understand.
So my question is this, when there’s something like a blocking call, does a .net application start running a background process (such as garbage collection) while the main thread of execution is blocked?
Thank you for your time.
Garbage collector has its own dedicated resources so it does not matter if you are using a blocking call or not.
Blocking call basically means running a long running task on the UI thread. Depending on the type of application (WPF, Windows, Console), definition of UI thread differs but while you are running a task on the UI thread, all messages for UI thread get queued up.
The effect you are seeing could be due to some other issues for example Disk or Network bottlenecks causing delay in the long running task. Using perfmon and matching the timing of your delays with the perfmon logs can be useful.