So I've got a bad idea: What if we embedded a prog...

# coroutines

[groostav]

So I've got a bad idea: What if we embedded a progress bar control and a delegating CoroutineDispatcher into a coroutineContext such that we could ~automagically make progress bars based on the number of suspension points?

I think this is akin to reflecting on the number of states the coroutine state machine has. Of course, while-loops and if-statements blow this up, but still I feel like there might be something here.

Has anybody got an implementation doing something like this?

[groostav]

I'm tired of replacing my buggy java-based progress-bar implementing spagetti code with kotlin coroutine backed code that is way more readable but only renders a spinner

[ephemient]

interesting thought but I have no idea how you would count the number of suspension points left to go

[gildor]

I don’t think it’s possible to do on level of coroutine dispatcher

[gildor]

Also I don’t think that it good enough to just count suspend points

[groostav]

@gildor no but its a start, to make it work youd need some pretty heavy static code analysis

[groostav]

you could do something like

fun launchProgressBarableTask(subtaskCount: Int, job: suspend () -> R): Deferred<R> { ... }

suspend fun enterSubtask(subtask: suspend () -> R): R { ... }

usage:

fun onUIEvent(){
  launchProgressBarableTask(subtaskCount = customers.size){
    for(customer in customers){
      results += enterSubtask {
        lookupCustomerDetailsFromSlowDB(customer)
      }

      publish(results)
    }
  }
}

[groostav]

you dont actually need enterSubtask since you can infer it from the dispatch but that seems really brittle to me

[groostav]

of course this also is just working with 1 level of the job tree

[groostav]

if we knew more about ther size of the job tree ahead of time we could build really high fidelity progress bars

[gildor]

wouldn’t be easier publish result explicitly?

[gildor]

I see your point, just curious is effort really worth it, maybe report progress explicitly is easier to maintain and it provides better progress reporting

[gildor]

It also may be pretty idiomatic with right dsl (because you alredy have launchProgressBarableTask which may provice custom scope in lambda):

fun onUIEvent(){
  launchProgressBarableTask(subtaskCount = customers.size){
    return mapWithProgress(customers) { customer ->
      enterSubtask {
        lookupCustomerDetailsFromSlowDB(customer)
      }
    }
  }
}

[gildor]

where mapWithProgress is a method of launchProgressBarableTask which reports progress for each item of customers and report it to launchProgressBarableTask