-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Stabilize CoroutineDispatcher.limitedParallelism #3864
Comments
Since I've started to advertise I'm afraid that this inconsistency will quickly become a gotcha. I think in the long run it's better to expose the internal unbounded dispatcher since it's already available via (It also feels like the inconsistency exists only for the sake of API beautification, I hope I'm wrong here, correct me, please) |
Can you be more specific, please, about the gotchas with |
Could you please provide a few examples where this behaviour is a problem or a gotcha that required a fix? |
This. When I've asked why another
That's what I mean by
And still it was not chosen, why? |
Basically the problem is that
|
I think this is a case where being too educated becomes a problem. IDEA writers are not our only users, and most of our users don't even know |
Another thing related to the intent of code. Some client, which the platform does not control, may regularly exhaust |
The case you're describing is an interesting one, thanks! The issue is, that we're a widely used general-purpose library, so each public definition has a cost. Introducing a whole new |
I'd expect that it would at least make the user think about why both Consider this:
Why Now, ( |
I understand your desire for a simpler conceptual model as someone who routinely looks into how coroutines work internally. You are right, exposing The problem is, that these details are almost always irrelevant, and by exposing them, we would only make it more difficult to understand what's important and what isn't, muddying the conceptual field in which people are actually operating. — I can only call my API endpoint one request at a time. How do I do that? Now imagine you're the guy asking the questions, but you don't have anyone to give you answers. All you wanted to do was create a connection pool that uses threads marked for I/O-bound work (because that's the level you operate on), but now you have to dig into liveliness, understand thread pools, scheduling, and so on. Coroutines are supposed to make multithreading easily available, not just dump another layer of complexity on top of what's already difficult about it. The fact that most people don't know about the 64-thread limit is a testament to it being unobtrusive in practice, not a thing to "fix." |
So
I totally understand and support that exposing If you don't want to expose
— I can only call my API endpoint one request at a time. How do I do that? This approach aligns with |
Even if we agreed, the ship has sailed: https://duckduckgo.com/?q="dispatchers.io.limitedparallelism"+!g&t=ffab&ia=web There's plenty of documentation that already points to Also, I feel that we're speaking past each other. As I see it, To reiterate my initial point: if you're deep enough to know about the 64-thread limit, you're deep enough to learn about elasticity easily. If you're tired of explaining elasticity to colleagues, you can introduce If you have some considerations other than API purity, like if you can imagine error-prone code resulting from people not knowing about elasticity, please share them. Could someone want to hit the 64-thread limit and be surprised when it doesn't happen in the presence of views? Why? |
How about exposing
which is pretty clear and makes the relationship between dispatchers (avoiding context-switch) obvious. Then we can still make IO special in a sense that when |
On a side note, there seems to be a misconception about While this might not be a goal of our documentation per se, it still would be nice to explicitly bust this myth |
In general, we received mostly positive feedback about the API shape, and there is no reason to keep it experimental any further.
Few things to address during stabilization:
limitedParallelism(1)
does not re-use the same thread all the time)CoroutineContext
indispatch
is either transparent or that it can be transparent to the underlying dispatcher to control scheduling tweaksisDispatchNeeded
and unconfined-like behaviour for limited parallelismlimitedParallelism(1)
propertiesThe text was updated successfully, but these errors were encountered: