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

Add priorities to Dispatcher Views API #3178

Closed
bubenheimer opened this issue Feb 8, 2022 · 2 comments
Closed

Add priorities to Dispatcher Views API #3178

bubenheimer opened this issue Feb 8, 2022 · 2 comments

Comments

@bubenheimer
Copy link

Could it make sense to revisit the issue of dispatching coroutines at different priority levels, based on the new Dispatcher Views API? The priority could be tied to the dispatcher view, for example limitedParallelism(parallelism, priority).

The issue of prioritized coroutine dispatching has come up several times before, e.g. #238, #476, #1617.

My use case is sound generation in an Android game, which needs to be as realtime as possible. Currently I use a dedicated thread with elevated thread priority, which seems expensive and not necessarily as realtime as I'd like due to thread switching. A Dispatcher View on top of Dispatchers.Default with a parallelism of 1 and maximized ("realtime") dispatch priority might be a better solution, if it were available. Reimplementing in C is another option here, but I don't want to go there.

@qwwdfsad
Copy link
Contributor

Thanks for the detailed explanation of your use-case!

Unfortunately, such API doesn't seem possible, because priority is not the property of view, but the property of an underlying dispatcher. If the dispatcher doesn't support it, then views won't either.

@qwwdfsad
Copy link
Contributor

qwwdfsad commented Apr 6, 2022

Closing as "won't fix for now".

Integrating priorities into existing dispatchers will be a significant performance hit, both from scheduling latencies and allocation pressure perspective -- for priorities, scheduler has to maintain any kind of concurrent balanced tree/heap/relaxed heap which are not easily optimizable and we are not ready to start working on that.

I would be delighted to see an external implementations though, for example, it could be a custom dispatcher that has the priority mechanism built-in and priorities accepted as part the first argument of dispatch(context: CoroutineContext, block: Runnable) method. Then we can evaluate it and see if kotlinx.coroutines can provide somehow unified access or API to that

Explicitly linking #238, #476, #1617 here so people can find this comment

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