Ce post est également disponible en francais. 

In a previous post, I talked about a feature of the .NET framework that allows to automatically pass information from a thread to any thread it spawns.

It turns out that not only the Call Context flows to the thread pool, but it also flows to any System.Threading.Timer and to IO completion related threads, such as in Sockets.

I was taken off-guard by the fact that in early stages of the server-side remoting pipeline, there were already information in the CallContext before the incoming message was deserialized. But the content was not exactly what I was expecting; it was the data that was in the CallContext when RemotingConfiguration.Configure() was invoked.

This makes sense, all the sockets used by TcpChannel or HttpChannel are created when calling this method, and asynchronous operations are started at this time. So, to avoid having the data to flow to the other side, there are these two methods on the ExecutionContext class to Suppress the flow and Restore it, which can prevent temporarily the Call Context from flowing.

This post is also available in french here. 

After reading this post from Eric Lippert, and reminding me that in the samples for this post, I'm using IEnumerable<T>.Count() where I'm actually not using the return value, therefore I'm enumerating through the whole collection for almost nothing.

I could have used IEnumerable<T>.Any(), which after looking at the IL code, just starts the enumeration, and stops just after one element if there is one and returns true, or if there isn't, returns false.

This is more effective, even without PLinq :)