https://kotlinlang.org logo
Channels
Powered by
#tornadofx
  • r

    ron

    01/14/2017, 6:34 AM
    mostly it is used when doing rest calls in the use cases I have heard about
  • r

    ron

    01/14/2017, 6:34 AM
    @elizarov you have answers 🙂
  • e

    elizarov

    01/14/2017, 6:37 AM
    My challenge is that I plan to have an 
    asyncRun { ... }
    coroutine builder in 
    kotlinx.coroutines
    to "fire-and-forget" new coroutine, but it has different threading semantics to 
    runAsync
    and I'd like to avoid confusion between the two by either picking a different name of adjusting its semantics.
  • r

    ron

    01/14/2017, 6:37 AM
    asyncRun
    would not report back at the end of the work?
  • e

    elizarov

    01/14/2017, 6:38 AM
    The simplest approach is to pick a different name, like 
    fork
    . But that has far-reaching implications is that every coroutine builder will have to be renamed to something else (right now they all like 
    asyncXXX
    , so you have a hint that some asynchronous activity is going to be started)
  • r

    ron

    01/14/2017, 6:39 AM
    well (coming from a C background) even a fork can report back result
  • e

    elizarov

    01/14/2017, 6:39 AM
    asyncRun
    would not report. 
    asyncValue
    will return an 
    AsyncValue
    (a non-blocking future) and if you like futures you could do 
    asyncFuture
    , or if you like Rx you could do 
    asyncObservable
    . Different coroutine builders have different result types.
  • r

    ron

    01/14/2017, 6:40 AM
    asyncRun
    does not make clear that it does not report back like 
    asyncValue
    does
  • r

    ron

    01/14/2017, 6:41 AM
    maybe 
    asyncVoid
    ?
  • e

    elizarov

    01/14/2017, 6:41 AM
    Picking a good a name for fire-and-forget is hard, but we need a separate name for that. Just use 
    asyncFuture
    and then ignore its result is not going to work, as any exception inside that coroutine is going to be stored in that future and if you did not use your future, then you'd never know it had crashed (very hard to debug!)
  • r

    ron

    01/14/2017, 6:41 AM
    oh I agree with that 🙂
  • r

    ron

    01/14/2017, 6:41 AM
    grins: 
    asyncForget
    ?
  • e

    elizarov

    01/14/2017, 6:42 AM
    In one prototype I had just 
    go
    (it is a keyword in Go language that does exactly that -- fire and forget new coroutine)
  • r

    ron

    01/14/2017, 6:42 AM
    for us the pattern 
    async { do something} ui { do something with the result }
    is important
  • e

    elizarov

    01/14/2017, 6:43 AM
    Too short for Kotlin style, though
  • e

    elizarov

    01/14/2017, 6:43 AM
    If you have non-blocking REST API, the you re code can become more natural.
  • r

    ron

    01/14/2017, 6:44 AM
    you want the 
    async
    in it to make clear it is a different thread
  • e

    elizarov

    01/14/2017, 6:44 AM
    Assume that instead 
    fun makeRestCall(...)
    you have 
    suspend fun makeRestCall(...)
    that does not block a thread. Then, instead of 
    runAsync { makeRestCall(...) } ui { result -> doSomethingWith(result) }
    you could just do 
    asyncRun { doSomethingWith(makeRestCall(...)) }
  • r

    ron

    01/14/2017, 6:45 AM
    why not just 
    async
    ?
  • r

    ron

    01/14/2017, 6:45 AM
    this is the current implementation of our runAsync
  • e

    elizarov

    01/14/2017, 6:45 AM
    It looks like different people want different 
    async
    , so we'd rather leave this name unused in the general library
  • r

    ron

    01/14/2017, 6:45 AM
    fun <T> runAsync(status: TaskStatus? = find<TaskStatus>(scope), func: FXTask<*>.() -> T) = task(status, func)
  • r

    ron

    01/14/2017, 6:46 AM
    and the task is
    Copy code
    fun <T> task(taskStatus: TaskStatus? = null, func: FXTask<*>.() -> T): Task<T> = FXTask(taskStatus, func = func).apply {
    setOnFailed({ Thread.getDefaultUncaughtExceptionHandler().uncaughtException(Thread.currentThread(), exception) })
    Thread(this).start()
}
  • r

    ron

    01/14/2017, 6:47 AM
    This is a very javafx implementation
  • e

    elizarov

    01/14/2017, 6:48 AM
    The plan to for 
    asyncRun
    (or how else we name it) is that in UI applications it schedules all continuation onto UI thread by-default. So your code in 
    runAsync { ... }
    is asynchronous (does not block a thread), but still runs inside an even-dispatch thread.
  • r

    ron

    01/14/2017, 6:48 AM
    we already changed the name once, it was first called 
    background
    somewhere in 1.4.7 I yhink
  • e

    elizarov

    01/14/2017, 6:48 AM
    If you want to escape to a different thread for compute-intensive stuff, then you'd explicitly tell like like this 
    asyncRun(myComputePool) { ... }
  • r

    ron

    01/14/2017, 6:49 AM
    suspend
    is a new keyword then?
  • e

    elizarov

    01/14/2017, 6:49 AM
    In Kotlin 1.1 
    suspend
    is a new soft-keyword
  • r

    ron

    01/14/2017, 6:52 AM
    but what about progress communication?
1...753754755...2007Latest