Using ComposeScenes with anything but MainUIDispatcher results in a deadlock
#4788
Comments
|
Unfortunately this is not currently a supported use-case. We tried to allow concurrent use of It's possible that we have since introduced our own, additional, limitations, since we've stopped trying to support concurrent use of |
|
Hasn't the linked issue been caused by multiple threads being used for the same scene due to |
|
No, it's about using multiple scenes concurrently. Why do you need to use multiple |
m-sasha
added
wait for reply
|
I have been using multiple scenes for a server-side GUI, where the server handles multiple users at once. The performance degraded severely now that everything has to use |
|
Can you try using a single-thread dispatcher instead of ? |
|
Yes, I tried that as well - it results in the same deadlock between that single-thread and the AWT event queue. |
|
Also, does this mean that using Compose to render into GLFW windows (for example using LWJGL) is unsupported now as well? (you have to use the glfw thread there, which clashes with the requirement for |
|
We can't support this use-case well because of the aforementioned limitations upstream (i.e. you could still get deadlocks before), and it's complicated to support it badly. |
|
The LWJGL thing mentioned in my last comment is something different though, no concurrent use of I don't think it caused any issues or deadlocks before - it was basically the same just with the difference that the entire logic did not have to run on No multithreading there, no concurrent scenes - it simply needs a different (single) thread because you cannot start a GLFW window in the AWT event queue. |
|
In all shared code snippets in the linked issue there are always thousand concurrent scenes started on different threads. I am not sure how one scene on a single thread could lead to the same issues described there. |
|
There are global structures in Compose that are shared between all instances, as explained in these two tickets: |
|
But I am not talking about multiple instances right now. Only a single scene, a single application, a single thread - so only one instance. The main issue is that a requirement for I opened this issue because of the requirement for |
|
Also, this is not an upstream issue, since upstream does not work with the AWT event queue and therefore cannot be the reason why it is required (except if somewhere in upstream Compose the coroutineContext is ignored and MainUIDispatcher has been hardcoded). |
|
I don't know whether supporting GLFW is an important goal for us. @igordmn ? |
|
We discussed it with @igordmn recently - it was a conscious, explicit decision to not depend on a specific dispatcher. |
|
The problem is likely that |
|
A simple alternative fix can be adding ability to redefine GlobalSnapshotManager's dispatcher |
Or:
|
Describe the bug
MultiLayerComposeSceneandSingleLayerComposeSceneprovide the option to set acoroutineContextparameter.FrameDispatcheralso provides the option to pass aCoroutineScopeorCoroutineContext.However, using a scene with any other dispatcher other than
MainUIDispatcher(provided by Skiko) will result in deadlock at some point when using the application.Since the render call on a scene must also be called from the same thread, this also means that the
FrameDispatchermust useMainUIDispatcheras well.This causes several issues. For example, GLFW requires the use of a specific thread to be able to draw to a Window, which clashes with the requirement for
MainUIDispatcherwhich is an AWT event queue.The following seems to be unsupported for now:
I consider this a major bug, since this makes it impossible to render multiple scenes at once using different threads (asMainUIDispatcheris always the same). Multiple scenes are needed if you wish to render multiple completely separate scenes in one Kotlin application. The coroutineContext paramters are also completly obsolete this way.Please note: In past Compose versions (for example
1.2.0)ComposeSceneworked fine with other dispatchers, so this is a new bug which has been introduced with recent updates.To Reproduce
MultiLayerComposeSceneDispatchers.Default.limitedParallelism(1)to itFrameDispatcherFrameDispatcherDeadlock:
Detailed Thread Dump Stack Traces
Expected behavior
It should be possible to pass a custom dispatcher to the scene APIs. E.g. your own
Dispatchers.Default.limitedParallelism(1). Alternatively, it could be possible to configure whatMainUIDispatcheractually is under the hood.This is needed for having multiple and completely separate scenes at once in one Kotlin application.(not supported, but it is still needed for reasons explained above)Custom scenes should not depend on the AWT event queue, since they won't be rendered to an AWT or Swing Window anyways.
Affected platforms
Versions
1.6.2and1.6.10-rc011.9.23x8621Additional context
ComposeScenewas still completely provided by Skiko) the API worked perfectly fine with any dispatcherMainUIDispatcher, which would explain why this issue has not occurred yet.The text was updated successfully, but these errors were encountered: