Is there a way to say "give me the coroutine context if I am in a coroutine"? I basically want/need a way to detect if I am running in a coroutine and to grab the context, even in a non suspending method. It that possible?

You can use the

coroutineContext

property but only in a suspend function or a

CoroutineScope

.

Yeh, I am looking for a way to detect if I am in a coroutine so I can't call a suspending property

You could declare your method an extension of

CoroutineScope

?

But I have no way of getting it right? What I want to be able to do is something like

fun hello(): CoroutineContext? {
    if(isInCoroutine) {
         return coroutineContext
    } else {
         return null
    }
}

No, there's no way to access that outside a suspend function or a

CoroutineScope

.

That is... disappointing.

Mind if I ask for your use case?

So, I have a scenario where I have an existing application that has this concept of a request context type thing, we call it a task context. People write their own methods that get called by our framework and they may call say TaskContext.get() to get some information about the request on top of what we pass in. We are in the process of moving some of our internal framework infrastructure over to coroutines, so we're using the coroutineContext to store what used to be the Task context. In order to avoid having to basically set a thread local every time we call into user code I was hoping there was a system to already do it so TaskContext could just get the coroutine that it is running in.

TaskContext

is a class with a static

get

method?

Yeh. So basically right now I have like

suspend fun someFrameworkFunction() {
 	TaskContext.push(ourSpecialCoroutineContext)
 	someUserFunction()
 	TaskContext.pop()
}

fun someUserFunction() {
	println(TaskContext.get().requestId)
}

Why not pass the TaskContext object as a parameter?

Oh, that is getting into really messy territory but the short answer is I can't 😛

Oh, okay. Bummer.

So it's not like the user implements an interface we control, it can be anything they want.

You cannot, maybe only if you use some stack trace walking and reflections

But even if I did that, I wouldn't be able to get the context right? So I'd still need some magic there.

But even if I did that, I wouldn’t be able to get the context right

Sure, only if you explicitly set it to ThreadLocal, but this is super messy, becaue one thread can handle many contexts, this is how coroutines work: reuse threads

Yeh, it's a tricky one.

I’m still not sure when you need this. Of course it can be useful in some tricky cases, but looks more like hack/workarond and probably make sense to reconcider your architecture

Not sure I agree with that. It's not a hack, assuming I could tell I was ultimately in a coroutine and get the context.

Problem that common (non-suspend) functions doesn’t have any context except Thread (which can be reused by multiple coroutines) and Stacktrace

Yeh, well at that point we're getting into the internal details of how coroutines are implemented. Like, for example how does Kotlin actually keep track of the context internally? Does it simply always pass it around, does it set a thread local before the scheduler schedules each task etc

Yes, Kotlin always pass it to each suspend function using continuation argument

Well, it would work if it did it before each continuation until it suspends and control goes back to the scheduler

Well, it would work if it did it before each continuation until it suspends and control goes back to the scheduler

yes fair point, looks that it’s possible, and even can be implemented with custom dispatcher, because coroutine dispatcher is just library class

Yeh, i am thinking that's the right approach. Either in my library code before I hand off, or a custom coroutine dispatcher. Thanks for your help!

Probably you should do something with this class https://github.com/Kotlin/kotlinx.coroutines/blob/master/core/kotlinx-coroutines-core/src/scheduling/CoroutineScheduler.kt or with https://github.com/Kotlin/kotlinx.coroutines/blob/master/core/kotlinx-coroutines-core/src/scheduling/Dispatcher.kt

You can use a

ThreadLocalContext

. Make a global ThreadLocal that's updated with the context whenever the coroutine thread changes, and cleared when the coroutine completes. You just need to add it to your context whenever you launch a coroutine.

Yes, Dico is absolutely right, just found ThreadContextElement API https://github.com/Kotlin/kotlinx.coroutines/commit/7587eba96a230f3f0ab0c04f52723e926f7a845d

You can use the code here: https://gist.github.com/Dico200/0de362aabcc0bfd6e6f6bf4f591a8055

We are in the process of moving some of our internal framework infrastructure over to coroutines, so we're using the coroutineContext to store what used to be the Task context.

It sounds like you had a way of passing your own context around before that worked. Why not just keep that architecture? Sounds like you're trying to use coroutine context for more than it was intended. Coroutine context is just that - the context of a coroutine - if you have your own concept of context for your own architecture it probably makes sense to keep modelling that explicitly.

If they used a

ThreadLocal

before, they need to use

CoroutineContext

now because coroutines can change thread. This solution might not use the coroutine context the way it was intended, that doesn't make it inherently bad. Either that, or they have to add parameters for the task context all over the code base (if they aren't there yet...) They could also use

ThreadContextElement

to store

TaskContext

instead of the

CoroutineContext

.

Either way, sounds like this system is trying to use some clever tricks to implicitly provide access to a very important part of its API and that's why it feels so awkward. Ideally the architecture would be more explicit about how the context is stored/owned, but I guess that sort of change is out of scope?

You are right. I'm not designing it.

Yeh. I’m not saying the API is necessarily correct just that we need to continue to support it. You can think of a Task as being broadly similar to a coroutine and the TaskContext is our version of the coroutine context or thread locals if you were doing it manually. Changing the customer facing API is a non starter so I need to replicate the existing behaviour.

Hope the thing in the gist I linked works for you then

I’m not sure the API is necessarily bad though. It’s very similar to things like request context when you are using spring, jax-rs etc. Or Akka context.