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.