Hello! After upgrading compose desktop from 1.5.10...
# compose-desktop
p
Hello! After upgrading compose desktop from 1.5.10-beta02 to 1.5.10-rc01 my app starts shutdown with delay. The reason is that after that upgrade two non daemon threads appeared (may be created by chached thread pool) that keep app in running state for sometime. When taking thread dump while delaying I can see that they are named as 'pool-1-thread-1@5997' and they are in java.lang.Thread.State: WAITING. When downgrading back to version 1.5.10-beta02 there is no delay.
m
Must be somehow application specific because my app still terminates immediately. (Tested on macOS Ventura.)
e
Hi, can you file an issue with a repro please? That will help us to investigate it.
p
Hello! I'll try to minimize it for repro.
e
Thank you!
p
I've found the place where non daemon threads created. it is at Skiko library (version 0.7.80) at org.jetbrains.skiko.HardwareLayer:132 where FrameLimiter is created with context of Dispatchers.IO. And in FrameLimiter in init clause there is launch with this dispatcher with infinite loop in it. So in 1.5.10-beta02 Dispatchers.IO dispatch this launch to DefaultDispatcher-worker that is daemon, and in 1.5.10-rc01 it distatched to pool-1-thread-1 wich is not daemon.
👀 1
🙏 2
In org.jetbrains.skiko.redrawer.LinuxOpenGLRedrawer there is dispose method in which this job is cancelled. But threads remains for sometime in cached thread pool (Dispatchers.IO is based on this kind of pool).
May be this problem is more about Coroutine dispatchers. Why Default's threads are daemons but IO's are not. May be the solution is to make IO's threads also daemons?
e
Thank you for such a detailed analysis. We are going to look into it.
👍 1
i
Thanks! Will be fixed in 1.5.10-rc02
Why Default's threads are daemons but IO's are not
IO dispatcher creates daemons. The issue was that we created new dispatcher instead of IO.