I have to use an API that accepts an `Executor` as a parameter. How can I create an `Executor` that ...

# coroutines

[zak.taccardi]

I have to use an API that accepts an Executor as a parameter. How can I create an Executor that is backed by Dispatchers.Default? There is no CoroutineDispatcher.asExecutor() function unfortunately

[zak.taccardi]

I don’t want to spin up a new thread unecessarily

[Adam Powell]

what's the rest of the api

[zak.taccardi]

https://developer.android.com/reference/androidx/biometric/BiometricPrompt.html#BiometricPrompt(androidx.fragment.app.FragmentActivity,%20java.util.concurrent.Executor,%20androidx.biometric.BiometricPrompt.AuthenticationCallback)

[zak.taccardi]

specifically that

[zak.taccardi]

I added a feature request for it here https://github.com/Kotlin/kotlinx.coroutines/issues/1450

[Adam Powell]

backing it with a dispatcher isn't going to do much for you in terms of bootstrapping into coroutine-world

[zak.taccardi]

I just want the Biometric API to use an already existing thread pool

[zak.taccardi]

instead of spinning up a new thread

[Adam Powell]

you can also just use any old handler's myHandler::post as an Executor and bounce off the main thread, no need to spin up a different one

[Adam Powell]

if you're processing the results elsewhere you probably want to offer into a channel that you're receiving on or similar instead, from the callback, and just use a directExecutor to do it. It doesn't really matter where the callback is dispatched then

[zak.taccardi]

I’m not sure what you mean by a direct executor

[Adam Powell]

a direct executor is one that just runs an incoming runnable inline without any sort of dispatching

[zak.taccardi]

but yeah, I would be sending the results to a channel that would be consumed on the main or a Dispatchers.Default thread

[Adam Powell]

if your callback implementation just offers into a channel (or the channel of a callbackFlow, or similar) then there's no reason to have the executor bounce between threads an extra time

[zak.taccardi]

the UI would consume the channel and send the result to the ViewModel which processes intentions/actions on Dispatchers.Default

[Adam Powell]

whatever you like 🙂 the important part here is that if you're already doing a thread or dispatch hop by sending through a channel or resuming an intercepted continuation, you don't need the Executor to define where the callback should run - it doesn't matter since you're doing your own dispatch into coroutines-land inside the callback itself.

[zak.taccardi]

ahh, interesting. the thread the callback executes on doesn’t matter because it will be sent elsewhere anyway 👍

[Adam Powell]

yep

[Adam Powell]

so you might as well use the fastest executor you can (direct) since you can guarantee that the callback won't block the calling thread

[Dico]

val executor = Executor { 
    GlobalScope.launch { it() }
}

[Dico]

Uses default dispatcher