louiscad
06/28/2018, 3:07 PMkenkyee
06/29/2018, 7:42 PMcoder82
07/01/2018, 8:27 AMcoder82
07/01/2018, 8:30 AMcoder82
07/02/2018, 9:46 PMigorvd
07/03/2018, 1:34 PMspand
07/04/2018, 5:31 AMcounter
variable ? ie. that the latest write to counter
is always read by the next processing thread?
fun counterActor() = actor<CounterMsg> {
var counter = 0 // actor state
for (msg in channel) { // iterate over incoming messages
when (msg) {
is IncCounter -> counter++
is GetCounter -> msg.response.complete(counter)
}
}
}
coder82
07/04/2018, 8:22 AMlouiscad
07/05/2018, 8:17 AMonEach
function for ReceiveChannel
?louiscad
07/05/2018, 8:46 AMredrield
07/07/2018, 8:44 PMSlackbot
07/08/2018, 4:59 PMrahulrav
07/08/2018, 5:29 PMprivate fun defaultExecutor(): ThreadPoolExecutor {
val maxPoolSize = Runtime.getRuntime().availableProcessors() * 3
val keepAliveTime = 2L // in seconds
val queue = LinkedBlockingQueue<Runnable>()
return ThreadPoolExecutor(0, maxPoolSize, keepAliveTime, TimeUnit.SECONDS, queue, ThreadManager.currentRequestThreadFactory())
}
Note the use of the ThreadManager.currentThreadRequestFactory()
.
Every time I invoke a suspend
function I ensure that it is accompanied by a withContext(...)
which uses the above defined coroutine dispatcher.
I see that sometimes, I get `Exception`s on App Engine, claiming I am trying to get an instance of supporting services (like Datastore or Memcache) on a thread which was not created by their thread factory (ThreadManager
). This typically happens in a coroutine's resume
method. Any ideas on what I might be doing wrong ?noncom
07/10/2018, 1:46 PMnoncom
07/10/2018, 1:47 PMrocketraman
07/10/2018, 5:18 PMlog
showing a DefaultExecutor
context and not SINGLE-THREAD
?nwh
07/11/2018, 10:50 PMJonathan Walsh
07/11/2018, 11:07 PMbj0
07/11/2018, 11:11 PMgroostav
07/13/2018, 5:34 AMlouiscad
07/13/2018, 12:42 PMDominaezzz
07/15/2018, 5:59 PMmakeRequest(): Request
, Request.isDone(): Boolean
, Request.cancel()
and Request.getResult(): Result
are available.mcastiblanco
07/16/2018, 12:57 AMhandleCoroutineException()
tries to forward/handle the exceptions. So my question is: is the call to handleCoroutineException()
generated by the compiler? maybe as part of the Continuation
or by wrapping the state machine with a trycatch?louiscad
07/16/2018, 7:34 AMjob.cancel(IllegalStateException(...))
from a callback, catch exceptions from the parent coroutine, but still get my app crashing. I replicated the issue in some tests, and the catch block is hit, but it seems the Exception is thrown no matter if it was caught in the parent coroutine. Is this really intended?louiscad
07/16/2018, 3:12 PMrunBlocking
as their body, never returning while the inner coroutine is run successfully?nwh
07/18/2018, 5:40 PMlouiscad
07/20/2018, 6:08 AMsuspend operator fun
that does what you need without blocking.giso
07/20/2018, 9:49 AMnwh
07/20/2018, 7:39 PMspierce7
07/21/2018, 3:10 AMspierce7
07/21/2018, 3:10 AMVsevolod Tolstopyatov [JB]
07/21/2018, 12:31 PMMy team is already busy filling in other library gaps we have for MPPCould you please elaborate what is missing (and is crucial for you)? We have a lot of thoughts what should be done for MPP (serialization, hashing, specific data structures, Guava stuff, proper CLI etc.), but it’s just too much. And you are one of the earliest adopters of iOS+Android mpp, it would be great to hear your opinion
I’m more or less just curious when we were going to see something materialize on the cold streams frontI think I’ll start prototyping it in the middle of Q3. Our priority is K/N coroutines and structured concurrency (https://github.com/Kotlin/kotlinx.coroutines/issues/410) now. The latter is important to get done because it affects every subsequent design decision and will break backward compatibility for basically every coroutine builder (and we can’t afford that after
1.0
version)