but its in scala

I was just thinking it would be nice if you were only working in a single context (like UI, or a single thread), that it would be nice to make the default "keep using current context"

@mkobit: it works, but it is a kludgy way to do it. You should just add

kotlinx-coroutines-jdk8

module to your deps and use

process.onExit().await()

.

Maybe a class that implements Handler and has a fun that returns a ProducerJob which sends anything the handler receives?

I'm also wondering how I could send the same message to multiple channels (not fanOut in the docs..) from one

produce { }

function?

to bridge the gap with a legacy system

Even inside

suspendCoroutine

? That means that block finished executing before the result is returned?

@elizarov I am starting to work on Reactor and Spring support for co-routines, as a beginning I have submitted this PR (https://github.com/Kotlin/kotlinx.coroutines/pull/141).

reactor-core

3.1 (included in

Bismuth

) is the real GA since the one shipped with Spring Framework 5 for which we garantee API stability, so no need to support the old one.

Yep... I'd guess the server has to be launched first... Looks like it's done at the end. Actually brings up an interesting question if you launch a bunch of coroutines and join later... Is there any way to get them to run sequentially or would you have to launch one from within another to do it. Though I can't think of a reason to ever need to do this 😀

📣 📣 📣

kotlinx.coroutines

version

0.19.1

is released. It is a patch that fixes a serious race in

ArrayBroadcastChannel

(it was there since introduction) and updates

kotlinx.coroutines.reactor

to leverage Bismuth release train. Full list of changes in here: https://github.com/Kotlin/kotlinx.coroutines/releases

@elizarov We are using coroutines to achieve monad bind syntax in Kategory generalized to all monads and it looks like this for example with Option.

Option.monad().binding {
  val a = Option(1).bind()
  val b = Option(a + 1).bind()
  yields(b)
}
//Option(2)

binding

is a Continuation and

bind

is implemented as a

COROUTINE_SUSPENDED

function that unwinds

flatMap

calls until the entire binding is completed as shown here https://github.com/kategory/kategory/blob/master/kategory-core/src/main/kotlin/kategory/typeclasses/MonadContinuations.kt#L53-L61 For this to work we are resorting to a dirty hack which is making the private

label

and

completion

properties visible so we can mutate them accordingly. https://github.com/kategory/kategory/blob/master/kategory-core/src/main/kotlin/kategory/typeclasses/ContinuationUtils.kt Do you know if there is a better way of doing this? Thanks in advance for any pointers in the right direction 🙂

@voddan 0.19.1 is in central

it doesn't seem to match 0.19.1

Check out my new article about simple android app using coroutines: https://blog.elpassion.com/create-a-clean-code-app-with-kotlin-coroutines-and-android-architecture-components-f533b04b5431

>> put multiple containers into one JVM instance, which allows to deploy many small Java applications in large scale, across data centers,

use coroutines (from Da Vinci Machine project) to reduce context switches, implement quick Java warmup to obviate the need for “warming-up” occurred in initialization phase of the eCommerce applications

@rrva Conceptually, it is the same. Just a different name for the same concept. https://en.wikipedia.org/wiki/Fiber_(computer_science)

Hi there, may I have a hopefully quick review please? I'm trying to implement a version of

select

that waits for the first successful result (opposed to the existing one that waits for the first completed clause, no matter exceptionally or not). First of all, am I reinventing the wheel? If not, here's what I ended up with – does it make sense? Any issues you can see here?

private suspend fun <R, D : Deferred<R>> selectFirstSuccessful(deferredList: List<D>,
                                                               failedDeferredList: List<D>): Triple<R?, List<D>, List<D>> =
        if (deferredList.isEmpty()) {
            Triple(null, deferredList, failedDeferredList)
        } else {
            try {
                select<Triple<R?, List<D>, List<D>>> {
                    deferredList.forEach { deferred ->
                        deferred.onAwait { result -> Triple(result, deferredList - deferred, failedDeferredList) }
                    }
                }
            } catch (e: Exception) {
                val completedExceptionally = deferredList.filter { it.isCompletedExceptionally }
                val notCompletedExceptionally = deferredList - completedExceptionally
                selectFirstSuccessful(notCompletedExceptionally, completedExceptionally + failedDeferredList)
            }
        }

Full code with usage example is here: https://gist.github.com/detouched/73f366cb730ece629b9141dea96d3a98

@elizarov How will that help with awaiting for the first actually successful coroutine? Never failing one will still have to return something — some "empty" value I guess. Or do you mean keeping this approach but simplifying it by calling self in

onAwait

instead of

catch

in the case

result

is "empty"? I'm actually interested in the failures in some cases, so I need to somehow pass them through anyway to inspect them later.

Coroutines are good if your work that you have to do on each element is asynchronous (needs to wait for something, like network call). If it is all just CPU-bound, you’d be better off using Java parallel streams — they are specifically optimized for parallelization of CPU-bound computations.

@dave08 I’m somewhat lost at what problem you are trying to solve and what is the solution your are trying to apply. I don’t see how sending over channel inside a mutex should do anything. Can you post somewhere (like a gist) a larger example (a unit test, maybe?) that demonstrates what you are trying to do and what does not work?

like this in the example above:

counter.send(GetCounter(response))
    println("Counter = ${response.await()}")
    counter.close() // shutdown the actor
}

asyncio

analogue is a work in progress still. We’ll have some separate guide for it when it is released

But a with a buffer, offer does it when it can, or still returns false?

Hi! I recently encountered a strange behavior. I have a

HashMap

which is only accessed and modified in a single coroutine context:

val pushNotificationGeneratorThread = newSingleThreadContext(name = "Push Notification Generator Thread")
suspend fun clear() = run(pushNotificationDispatcherThread) {
    lastNotificationDates.clear()
  }
suspend fun put(key: String, value: Any) = run(pushNotificationDispatcherThread) {
    lastNotificationDates.put(key, value)
  }

However sometimes I still get a

ConcurrentModificationException

. In my understanding this should be threadsafe.

Hello all, I've been reading the docs and the KEEP, but I'm not sure I fully understand what coroutines offer. The example I've been keeping in my head is a server that responds to all requests with a randomly selected quote that it retrieves from a remote service. The call to that service and the response sent back to the client is done on a separate thread than the one the request comes in on. Using vanilla executors we would pass a

Runnable

that makes the network call and writes the response. Using Rx it would look something like:

quoteService
    .getQuote()
    .flatMap(response::write)
    .subscribeOn(<http://Schedulers.io|Schedulers.io>())
    .subscribeBy(
      onSuccess = {},
      onError = {}  
    )

I'm not great with coroutines, but I assume it would look something like:

async {
  try {
    val quote = quoteService.getQuote().await()
    response.write(quote)
  catch(_: Exception) {}
}

Is it just about the style of programming, or do coroutines offer something major over the other approaches? I see a few places that mention coroutines are non-blocking, but they don't seem to be, at least not in the same way that non-blocking io works. Can anyone help clarify this?

a system property is mentionned in this issue to ease the debugging of stacktraces in coroutines : https://github.com/Kotlin/kotlinx.coroutines/issues/74 . Somebody knows if it was ever implemented ?

You get better with channles/actors only when the channels are not hidden behind methods, so you can can build async processing pipelines with them.

Yes, looks like it 🙂 The beauty of coroutines is, that you have a sequential flow, even with suspension points.

Elizarov answered that channels are async, im trying to approach from the sequence end to understand if they are not async, how are they different from regular kotlin sequences?