ThreadContextElements are not nested properly

[akalini]

Hello!

For some of the implementations of the ThreadContextElements the order of invocation is important. Here is one example that we are struggling with and don't know how to solve cleanly:

• Kotlin gRPC library has GrpcContextElement that propagates gRPC context.
• The element above attaches and detaches gRPC context
• We have additional gRPC context elements that we want to propagate. This is to support opencensus trace contexts which uses gRPC context for the implementation.
• Kotlin coroutines library invokes restoreThreadContext in exactly the same order as updateThreadContext.
• But the order in which detach calls happen need to be the opposite of attach calls (required by gRPC).

Is there a reason why the order for restoreThreadContext is not the opposite of updateThreadContext?

[qwwdfsad]

Hi,

Is there a reason why the order for restoreThreadContext is not the opposite of updateThreadContext?

This behaviour is implementation-driven, at that point it was the most efficient way to implement it in the most performant way. Both updateThreadContext and restoreThreadContext are performance-sensitive because they are invoked on each resume and suspend. Your concern wasn't really considered back then.

Thanks for the report, this is definitely an issue worth re-considering for 1.4