https://kotlinlang.org logo
Channels
Powered by
#coroutines
  • m

    marcinmoskala

    01/29/2018, 5:20 PM
    I understand that it is waiting for 
    Job
    complition, but what are the dangers of lack of 
    join
    ?
  • j

    jw

    01/29/2018, 6:01 PM
    cancelation is not instantaneous
  • j

    jw

    01/29/2018, 6:02 PM
    so you might observe side-effects after cancel without a join
  • e

    elizarov

    01/29/2018, 6:06 PM
    @marcinmoskala +1 to @jw. You might see “spurious concurrency”. 
    cancel
    just signals “start shutting down please”, and if you don’t 
    join
    your code might be doing stuff concurrently with another coroutine that is still shutting down.
  • e

    elizarov

    01/29/2018, 6:20 PM
    📣📣 📣 
    kotlinx.coroutines
    version 
    0.22.1
    is released with a number of bug fixes: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.22.1
    🎉 15
  • r

    r4zzz4k

    01/29/2018, 6:30 PM
    Wow, we already have updated 
    runBlocking
    handy!
  • g

    groostav

    01/30/2018, 12:56 AM
    I'm poking around with some of the coroutine context stuff and i cant for the life of me get my 
    CoroutineExceptionHandler
    executed. can one of you guys take a peek and tell me what im missing?
  • g

    groostav

    01/30/2018, 12:56 AM
    "handled!" never gets printed
    cant_get_my_handler_called_kt.kt
  • j

    jw

    01/30/2018, 5:02 AM
    how do I build a source such that it can be used in a select?
  • j

    jw

    01/30/2018, 5:05 AM
    it seems like the mechanisms channels use can't be implemented in a general way
  • j

    jw

    01/30/2018, 5:05 AM
    ah might just be an IDE problem resolving 0.22.1
    ☝️ 1
  • e

    elizarov

    01/30/2018, 6:58 AM
    @jw The mechanics behind 
    select
    are supposed to be general, though API for that (
    registerSelectClauseX
    methods and 
    SelectInstance
    interface) is still somewhat unstable. It needs design review and maybe some simplification.
  • b

    btw

    01/30/2018, 7:49 AM
    I asked a technical question about coroutine mutex a month ago: https://discuss.kotlinlang.org/t/mutex-implementation-question/6095
  • b

    btw

    01/30/2018, 7:49 AM
    Any experts here?
  • e

    elizarov

    01/30/2018, 11:02 AM
    @btw I’ve missed it. Sorry. I’ll answer in the discussions.
  • d

    dstarcev

    01/30/2018, 11:26 AM
    When designing an asynchronous 
    interface
    , should I mark functions with 
    suspend
    or should I return 
    Deferred<T>
    ?
  • d

    dstarcev

    01/30/2018, 11:27 AM
    Copy code
    interface SmsService {
    suspend fun send(phone: String, message: String)
}

interface SmsService {
    fun send(phone: String, message: String): Deferred<Nothing>
}
  • d

    dstarcev

    01/30/2018, 11:27 AM
    which one is better?
  • l

    louiscad

    01/30/2018, 11:28 AM
    The former can be wrapped into an async block that will return a deferred
  • l

    louiscad

    01/30/2018, 11:29 AM
    If you don't need what 
    Deferred
    provides and just have the function to 
    suspend
    is enough, then use 
    suspend
    , it will save a 
    Deferred
    implementation instance to be created
  • e

    elizarov

    01/30/2018, 11:30 AM
    👍Always prefer 
    suspend
    , unless you have some interop requirements that mandate that you use futures.
    👍🏽 2
  • d

    dstarcev

    01/30/2018, 11:31 AM
    thanks guys
  • d

    dstarcev

    01/30/2018, 12:40 PM
    What are the cons of making all the functions 
    suspend
    when design a non-blocking service?
  • d

    dstarcev

    01/30/2018, 12:41 PM
    At the interface level we are not allowed to suppose what the concrete implementation will be
  • d

    dstarcev

    01/30/2018, 12:42 PM
    So there is always a chance it will be asynchronous
  • d

    dstarcev

    01/30/2018, 12:42 PM
    But not necessarily
  • d

    dstarcev

    01/30/2018, 12:43 PM
    If we make some interfaces 
    suspend
    and the other not, it will be kind of leaky abstraction
  • e

    elizarov

    01/30/2018, 12:46 PM
    Rule of thumb of simple. You mark functions with 
    suspend
    when you expect their implementation to be non-blocking to the invoker thread (aka “asynchronous”). So, if I read your API and see 
    interface Foo { fun doSomethingNetworkRelated() }
    , then I immediately see that 
    doSomethingNetworkRelated
    is going to block my thread while it does its network stuff. However, if I see 
    interface Foo { suspend fun doSomethingNetworkRelated() }
    then I assume that implementation is non-blocking and can be safely used, for example, from my UI thread or from other precious event-loop.
  • e

    elizarov

    01/30/2018, 12:47 PM
    We cannot guarantee that implementations of suspend function are not going to block, but that is the convention nonetheless.
  • e

    elizarov

    01/30/2018, 12:49 PM
    I’d even say this a discipline. If you follow a discipline of implementing all 
    suspend
    function in a non-blocking way, then your code is going to be beautiful and scalable whether you are writing front-end or back-end code.
    👍🏽 1
    👍 9
    🎉 1
1...436437438...571Latest