This post is also available in english here .

Dans un précédent post, je parlais d'une fonctionnalité du Framework .NET qui permet de passer des informations automatiquement d'une thread vers toute autre thread qu'elle crée.

En fait, le contexte d'appel passe non seulement aux Threads du Thread Pool, mais également à toute instance de System.Threading.Timer et aux IO Completion Threads, comme celle utilisées avec les sockets.

J'ai été surpris par le fait que dans les premiers étages du pipeline remoting coté serveur, il y avait des informations dans le CallContext et ce bien avant que le message entrant n'ai été interprété. Mais cela n'était pas tout à fait ce à quoi je m'attendais; c'était des données qui étaient présentes dans le contexte d'appel lors de l'appel à RemotingConfiguration.Configure().

Cela prend du sens, puisque tous les sockets utilisés par le TcpChannel et HttpChannel sont créés lors de l'appel à cette méthode, et des opérations asynchrones sont démarrées à ce moment la. Donc, pour éviter d'avoir les données qui transitent de l'autre coté, il y a ces deux méthodes sur la classe ExecutionContext pour supprimer et restaurer le passage du context d'appel.