Skip to content
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

Android Thread handling issue #1286

Closed
Tolriq opened this issue Jun 21, 2019 · 3 comments
Closed

Android Thread handling issue #1286

Tolriq opened this issue Jun 21, 2019 · 3 comments
Assignees

Comments

@Tolriq
Copy link

Tolriq commented Jun 21, 2019

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)

@qwwdfsad qwwdfsad self-assigned this Jun 24, 2019
@qwwdfsad
Copy link
Collaborator

qwwdfsad commented Jun 24, 2019

Thanks for the feedback!

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

@Tolriq
Copy link
Author

Tolriq commented Jun 24, 2019

Thanks for answering.

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?

@qwwdfsad
Copy link
Collaborator

It's another bug/side-effect :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants