-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using ComposeScene
s 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 |
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
MultiLayerComposeScene
andSingleLayerComposeScene
provide the option to set acoroutineContext
parameter.FrameDispatcher
also provides the option to pass aCoroutineScope
orCoroutineContext
.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
FrameDispatcher
must useMainUIDispatcher
as 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
MainUIDispatcher
which 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 (asMainUIDispatcher
is 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
)ComposeScene
worked fine with other dispatchers, so this is a new bug which has been introduced with recent updates.To Reproduce
MultiLayerComposeScene
Dispatchers.Default.limitedParallelism(1)
to itFrameDispatcher
FrameDispatcher
Deadlock:
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 whatMainUIDispatcher
actually 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.2
and1.6.10-rc01
1.9.23
x86
21
Additional context
ComposeScene
was 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: