What "Current" properties flow with ExecutionContext

Question

This is a two part question:

Can someone provide a list of the ASP.NET/.NET properties that are typically thread local that flow with ExecutionContext?

HttpContext.Current? Thread.CurrentContext? Thread.CurrentPrincipal? Thread.CurrentCulture?

What properties can I count on surviving/persisting async/await?

What else?
Is there any way to add application specific Context information that will flow automatically with ExecutionContext? Something like
```
var ec = ExecutionContext.Capture();
ec.CustomContext["MyCustomContext"] = ACustomContext;
```

What are you actually trying to do? Why do you feel the need to store a custom context? — Reed Copsey, Jun 21 '13 at 18:35
If you have two separate questions, *you should ask two questions*. — svick, Jun 21 '13 at 19:12
@ReedCopsey, I'm trying to refactor some legacy code that makes use of ThreadStatic and other thread local storage mechanism so that it will play nice with async/await. — Joe Enzminger, Jun 21 '13 at 20:18
@JoeEnzminger, you may want to check this: http://referencesource.microsoft.com/#mscorlib/system/threading/executioncontext.cs#3a777fa35a9f1ffe — noseratio, Mar 07 '14 at 00:56

score 14 · Accepted Answer · edited Dec 21 '21 at 06:59

14

The best resource for this is ExecutionContext vs. SynchronizationContext by Stephen Toub. There is no list of properties like what you're looking for.

ASP.NET actually uses SynchronizationContext to flow HttpContext.Current, and treats Thread.CurrentPrincipal rather oddly.

You can add your own context using LogicalSetData/LogicalGetData. However, you should only store immutable data. I document this on my blog.

edited Dec 21 '21 at 06:59

crouleau

answered Jun 21 '13 at 18:41

Stephen Cleary

Thanks (for LogicalSetData/LogicalGetData). I'd read each article you mentioned already, but it still left open the question of what framework context's flow. Seems like something that would be important to document... – Joe Enzminger Jun 21 '13 at 20:23
@JoeEnzminger: BTW, I don't *recommend* logical get/set data. It's just *possible* to use if you can't find another solution. I haven't run benchmarks but I would expect it's much slower than `ThreadStatic`. Explicit method arguments or instance fields would be my solution of choice. – Stephen Cleary Jun 22 '13 at 17:53
1

+1. It's interesting to see what actually gets flowed, albeit undocumented: http://referencesource.microsoft.com/#mscorlib/system/threading/executioncontext.cs#3a777fa35a9f1ffe. Especially interesting how synchronization context gets flowed explicitly via `ExecutionContext.Run`, but not implicitly. – noseratio Mar 07 '14 at 00:41
1

@Noseratio if you read Toub's linked article (specifically the last paragraphs) you'll see that `SynchrnoizationContext` is actually **not** flowed most of the time (not sure what you meant by explicitly/implicitly). – Ohad Schneider Jul 17 '17 at 22:02
2

@OhadSchneider, by *explicitly* I meant calling `ExecutionContext.Capture` and `ExecutionContext.Run` explicitly. By *implicitly* I meant just letting the async/await infrastructure flow it. – noseratio Jul 18 '17 at 11:40

1 Answers1