How do I use a specific thread as the thread that runs the coroutine?

[Black-tail]

For example, when I use the OpenGL drawing program in an Android project, the drawing thread of the OpenGL is not the Main thread. In this case, Dispatchers.Main is not applicable. How do I launch a coroutine on the OpenGL drawing thread? As far as I know, Dispatchers.unconfig is not applicable to this case either.

[fvasco]

You need a proper CoroutineDispatcher.

I don't know if one already exists, but implementing a new one is pretty easy, you should define the dispatch method only.

[qwwdfsad]

Indeed, you just have to define your own CoroutineDispatcher.
If you already have a java.util.concurrent.Executor for your OpenGL environment, you can convert it to the dispatcher via asCoroutineDispatcher extension

[feresr]

I'm also interested in this, can someone point to an example? I'm using GLSufraceView (Android) do I need to build my own OpenGL context with EGL instead?

[xloger]

A OpenGL CoroutineDispatcher like this:

class GlCoroutineDispatcher: CoroutineDispatcher() {

    companion object {
        val Instances = GlCoroutineDispatcher()
    }

    private var dispatcher: ((Runnable) -> Unit)? = null

    override fun dispatch(context: CoroutineContext, block: Runnable) {
        val useDispatcher = dispatcher
        if (useDispatcher != null) {
            useDispatcher.invoke(block)
        } else {
            Log.e("GlCoroutineDispatcher", "GlCoroutineDispatcher.dispatcher is null.Maybe you need call `Dispatchers.GL.init(binding.glTextureView)`")
            block.run()
        }
    }

    fun init(glTextureView: GLTextureView) {
        dispatcher = {
            glTextureView.queueEvent(it)
        }
    }

    fun release() {
        dispatcher = null
    }
}

val Dispatchers.GL: GlCoroutineDispatcher
    get() = GlCoroutineDispatcher.Instances

Initialize only need to bind the GLTextureView when onCreate：

Dispatchers.GL.init(binding.glTextureView)

If you not use GLTextureView，just rewrite dispatcher by glThread.queueEvent(r).

call like this:

withContext(Dispatchers.GL) {
    GLES20.glClearColor(0f, 0f, 0f, 0f)
    //do something
}

[gmazzo]

This is my implementation for Android:

@ActivityScoped
class GLDispatcher @Inject constructor(
    private val view: GLSurfaceView,
) : CoroutineDispatcher() {

    override fun dispatch(context: CoroutineContext, block: Runnable) {
        view.queueEvent { if (context.isActive) block.run() }
    }

}

https://github.com/gmazzo/android-weather-tree-live-wallpaper/blob/main/app/src/main/kotlin/io/github/gmazzo/android/livewallpaper/weather/GLDispatcher.kt

[fvasco]

@gmazzo context.isActive looks harmful to me, it can prevent releases of resources.
block should run unconditionally and you use ensureActive() in your code.

[gmazzo]

@gmazzo context.isActive looks harmful to me, it can prevent releases of resources. block should run unconditionally and you use ensureActive() in your code.

Good catch 💪 , I missed that, thanks! So, now, this is the implementation I'm using:

@ActivityScoped
class GLDispatcher @Inject constructor(
    private val view: GLSurfaceView,
) : CoroutineDispatcher() {

    override fun dispatch(context: CoroutineContext, block: Runnable) = view.queueEvent {
        context.ensureActive()
        block.run()
    }

}

it can prevent releases of resources

Assuming throwing CancellationException will release them, right?

[fvasco]

Assuming throwing CancellationException will release them, right?

@gmazzo No, block must be executed unconditionally, even when context has been cancelled.

Take a look here:

kotlinx.coroutines/kotlinx-coroutines-core/jvm/src/Executors.kt

Lines 129 to 137 in f4f519b

	override fun dispatch(context: CoroutineContext, block: Runnable) {
	try {
	executor.execute(wrapTask(block))
	} catch (e: RejectedExecutionException) {
	unTrackTask()
	cancelJobOnRejection(context, e)
	Dispatchers.IO.dispatch(context, block)
	}
	}

[gmazzo]

No, block must be executed unconditionally, even when context has been cancelled.

@fvasco I understand we are a bit diverging from the scope of this issue, but I really want to understand how "it can prevent releases of resources"

In my code, continuing with the block after the context is not active anymore will produce a crash (actually, this fixed all the crashes in the app) since the associated OpenGL instance has already been destroyed. Any glXXX operation, like glCreateTextures, will fail after the job is cancelled 🤔

[fvasco]

@gmazzo
This is a reproducer: no clean up invocation, job never completes and runBlocking hangs forever.

https://pl.kotl.in/76hGJuYDG

I suppose a better solution was already published, however for simple task you can consider:

suspend fun <R> GLSurfaceView.executeOnGLThread(block: () -> R): R =
    suspendCoroutine { cont -> queueEvent { cont.resumeWith(runCatching { block() }) } }

or something similar.

[gmazzo]

Actually I just read fully the doc of dispatch and

This method should guarantee that the given block will be eventually invoked, otherwise the system may reach a deadlock state and never leave it. The cancellation mechanism is transparent for CoroutineDispatcher and is managed by block internals.

What I don't get why my code wasn't canceled after the GL thread was destroyed 🤔 . I think I'll keep researching it. Thanks!

I may go back to the original one:

class GLDispatcher @Inject constructor(
    private val view: GLSurfaceView,
) : CoroutineDispatcher() {

    override fun dispatch(context: CoroutineContext, block: Runnable) {
        view.queueEvent(block)
    }

}

Or try your previous example.

[dkhalanskyjb]

Simply scheduling an event is the way to go. kotlinx.coroutines provides the "prompt cancellation guarantee" (please see https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/suspend-cancellable-coroutine.html) to ensure that coroutines resume with a CancellationException in cancelled contexts. If the context truly got cancelled and the code is normal kotlinx.coroutines usage, then either we have a bug somewhere, or your code contains something like

try {
  delay(100) // or some other suspend operation
} finally {
  // will run even if the context is cancelled
  doSomeOpenGlOperation()
}

Finalizers are guaranteed to run (that's by design, as they are involved in resource cleanups).