JoeHegarty
10/15/2018, 9:08 PMDominaezzz
10/15/2018, 9:14 PMcoroutineContext
property but only in a suspend function or a CoroutineScope
.JoeHegarty
10/15/2018, 9:16 PMDominaezzz
10/15/2018, 9:17 PMCoroutineScope
?CoroutineScope
.JoeHegarty
10/15/2018, 9:22 PMfun hello(): CoroutineContext? {
if(isInCoroutine) {
return coroutineContext
} else {
return null
}
}
hello
is not suspending so I have no access to any of the usual context stuffhello
was called from within a coroutine then I want to be able to get that context.Dominaezzz
10/15/2018, 9:32 PMCoroutineScope
.JoeHegarty
10/15/2018, 9:32 PMDominaezzz
10/15/2018, 9:36 PMJoeHegarty
10/15/2018, 9:40 PMDominaezzz
10/15/2018, 9:47 PMTaskContext
is a class with a static get
method?JoeHegarty
10/15/2018, 9:49 PMsuspend fun someFrameworkFunction() {
TaskContext.push(ourSpecialCoroutineContext)
someUserFunction()
TaskContext.pop()
}
fun someUserFunction() {
println(TaskContext.get().requestId)
}
TaskContext.get()
get the coroutineContextDominaezzz
10/15/2018, 9:53 PMJoeHegarty
10/15/2018, 9:54 PMDominaezzz
10/15/2018, 9:55 PMJoeHegarty
10/15/2018, 9:56 PMgildor
10/16/2018, 12:11 AMJoeHegarty
10/16/2018, 5:25 AMgildor
10/16/2018, 5:28 AMBut even if I did that, I wouldn’t be able to get the context rightSure, 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
JoeHegarty
10/16/2018, 5:29 AMgildor
10/16/2018, 5:30 AMJoeHegarty
10/16/2018, 5:31 AMgildor
10/16/2018, 5:32 AMJoeHegarty
10/16/2018, 5:33 AMgildor
10/16/2018, 5:34 AMJoeHegarty
10/16/2018, 5:35 AMgildor
10/16/2018, 5:40 AMWell, it would work if it did it before each continuation until it suspends and control goes back to the scheduleryes fair point, looks that it’s possible, and even can be implemented with custom dispatcher, because coroutine dispatcher is just library class
JoeHegarty
10/16/2018, 5:41 AMgildor
10/16/2018, 5:45 AMDico
10/16/2018, 1:34 PMThreadLocalContext
.
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.gildor
10/16/2018, 2:08 PMDico
10/16/2018, 2:35 PMZach Klippenstein (he/him) [MOD]
10/16/2018, 2:37 PMWe 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.
Dico
10/16/2018, 2:44 PMThreadLocal
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
.Zach Klippenstein (he/him) [MOD]
10/16/2018, 3:01 PMDico
10/16/2018, 3:02 PMTaskContext
they could possibly be implemented with an object that keeps a reference the task context.JoeHegarty
10/16/2018, 5:31 PMDico
10/16/2018, 5:35 PMJoeHegarty
10/16/2018, 5:35 PM