You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After trying to better understand why there was so much threads created for coroutines, I pushed the tests a little further and face something strange.
For tests I only use a dedicated ThreadPool with asCoroutineDispatcher() and a copy of the Main dispatcher to avoid disk access until 1.3 is out.
0 calls to Dispatchers.IO/Default/Main.
At application startup I have 3 to 4 DefaultDispatcher threads created, then over the course of the usage of the application more will be created until reaching the device max core count (8 in that cases).
Meaning 8 threads started that are not really used. (Probably a little for dispatching?)
Source of the issue was that when using also Dispatchers.IO the app always had 12 to 16 DefaultDispatchers threads even when doing nearly nothing. IO threads seemed to never be released and should probably not even have been started. (All long running tasks are started in a specific dispatcher with a lower thread priority, most IO calls are made via a worker pool limiting concurrency)
The text was updated successfully, but these errors were encountered:
Source of the issue was that when using also Dispatchers.IO the app always had 12 to 16 DefaultDispatchers threads even when doing nearly nothing.
Note that Dispatchers.IO and Dispatchers.Default share the same threads. Not like it justifies that amount of threads, but just to be clear.
This is limitations of current coroutine scheduler that I'd be better not to explain (a lot of internal concurrent machinery) that interfere in a strange way. I am currently improving the scheduler to fix #1046 and it looks like I can piggyback on these changes to resolve the problem with excessive threads as well
I'm aware about IO sharing but from my understanding and some comment read the superfluous IO thread should be released after some time and it seems it may not be the case.
Is there a very very long duration for the IO thread release? Or are IO not supposed to be released at all? Or is this another bug / side effect?
After trying to better understand why there was so much threads created for coroutines, I pushed the tests a little further and face something strange.
For tests I only use a dedicated ThreadPool with
asCoroutineDispatcher()
and a copy of the Main dispatcher to avoid disk access until 1.3 is out.0 calls to Dispatchers.IO/Default/Main.
At application startup I have 3 to 4 DefaultDispatcher threads created, then over the course of the usage of the application more will be created until reaching the device max core count (8 in that cases).
Meaning 8 threads started that are not really used. (Probably a little for dispatching?)
Source of the issue was that when using also Dispatchers.IO the app always had 12 to 16 DefaultDispatchers threads even when doing nearly nothing. IO threads seemed to never be released and should probably not even have been started. (All long running tasks are started in a specific dispatcher with a lower thread priority, most IO calls are made via a worker pool limiting concurrency)
The text was updated successfully, but these errors were encountered: