mp
02/12/2019, 2:02 PMantonis
02/12/2019, 2:10 PMmp
02/12/2019, 2:12 PMmarstran
02/12/2019, 2:22 PMmp
02/12/2019, 2:29 PMantonis
02/12/2019, 2:32 PMmp
02/12/2019, 2:34 PMantonis
02/12/2019, 2:34 PMmp
02/12/2019, 2:35 PMantonis
02/12/2019, 2:35 PMmp
02/12/2019, 2:35 PMantonis
02/12/2019, 2:40 PMmp
02/12/2019, 2:47 PMbdawg.io
02/12/2019, 2:54 PMmarstran
02/12/2019, 2:58 PMreceive
on response channel.bdawg.io
02/12/2019, 2:59 PMCompletableDeferred
is cheaper than a channel is.marstran
02/12/2019, 3:00 PMmp
02/12/2019, 3:09 PMbdawg.io
02/12/2019, 3:21 PMdata class WorkItem(val value: String, val response: CompletableDeferred<Response> = CompletableDeferred())
val workValues: ReceiveChannel<WorkValue> = getValues()
coroutineScope {
repeat(workerCount) {
launch {
doSomething(workValues.receiveNextTen())
}
}
}
mp
02/12/2019, 3:23 PMbdawg.io
02/12/2019, 3:29 PMmp
02/12/2019, 3:35 PMbdawg.io
02/12/2019, 3:36 PMmp
02/12/2019, 3:38 PMbdawg.io
02/12/2019, 3:47 PMval semaphore = Semaphore(10)
repeat(20) {
thread {
// blocking
semaphore.aquire()
try {
doSomething()
} finally {
semaphore.release()
}
}
}
vs val mutexPool = MutexPool(10)
repeat(20) {
launch {
// suspending
mutexPool.withLock {
doSomething()
}
}
}
I’m just trying to understand what “simpler” meansmp
02/12/2019, 4:22 PMmarstran
02/12/2019, 4:35 PMmp
02/12/2019, 5:07 PMbdawg.io
02/12/2019, 7:12 PMMutex
and select
from the core library).
I would still argue that it sounds like the design causing the need for a semaphore has an alternative that’s simpler and cleaner in coroutines, but I’m not that close to the original problem to say more.
The nice part is coroutines being open source makes it nice to open (or implement) feature requests. (Most of which either get implemented fairly quick or get rejected with a real reason)