https://kotlinlang.org logo
Join Slack
Powered by
reuses threads from CommonPool, why do you think t...
# coroutines
g
reuses threads from CommonPool, why do you think this is tricky?
v
@gildor creating a new thread pull with the same parameters (n + 1 thread) would be equally logical. Any good reason why one and not the other?
v
+
operator doesn’t copy all its arguments, it concatenates them, given you tree-like structure
v
So what do you consider "arguments" in this case? The OS threads? Or their number?
v
CommonPool
and 
CoroutineName
. It doesn’t matter, what hides behind 
CommonPool
, threads count or actual threads
v
I see, so it "encloses" the 2 contexts into a third one. This, BTW, contradicts the documentation explanation that "context is like a map" when in fact it is rather a tree of pairs.
v
It doesn’t contradict map contract. 
CoroutineContext
is still a map with key-value access. What may puzzle you is the fact that this map is immutable. For immutable maps there is no difference whether 
+
concatenates maps as a tree or actually copies all elements, it’s an implementation detail. E.g. Scala 
scala.collection.immutable.Map
behaves exactly the same way as 
CoroutineContext
. Also note, that there is no such standard container, which provides deep copy of elements. E.g. if you put 
CommonPool
into hash map and then call 
copy
on it, do you expect it to do deep copy of 
CommonPool
?
v
do you expect it to do deep copy of 
CommonPool
?
Ok that makes sense when I think about it
The problem I had (have?) is that I didn't consider coroutine context to be a container, but rather a stand-alone dispatcher with a hashmap of properties (aka "settings"). Then it all gets mixed up.
v
we’ll eventually improve our documentation about context and its interaction with 
kotlinx.coroutines
d
@Vsevolod Tolstopyatov [JB] Maybe enlist @Deactivated User for this, he's been doing a tremendous job w/ Ktor docs... unless he's too busy there?
I think coroutines really badly needs a best practices docs, on how to use them in more common use cases.
v
You’re right, we need best practices and more compact and “fluent” guide. The problem is in our API: it’s just not stable enough. We have a lot of plans how to change it to make it more obvious and less error-prone, but it would require rewriting all the guides we have.
d
It's the famous egg and the chicken problem... w/o a certain amount of docs, users won't know how to use things properly to give feedback on what could change and proper use cases... the current state is just too confusing. @Vsevolod Tolstopyatov [JB]
Properly documented guidelines don't have to take too much time for someone who knows the subject really well and can help tons of people already using coroutines in Production save tons of time and better enjoy the experience.
Until things change and are production-ready, feedback is really crucial, and I don't know how many are really holding at the point of giving that feedback.
Btw, I think Ktor is also changing...
g
I'm not sure why docs about context would be considered as bad or confusing. There is even section about combining of contexts: https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#combining-contexts
d
I didn't mean docs about combining contexts, I just meant that there's quite a bit of confusion about certain subjects in coroutines (just the last few days I spent lots of time with tests and coroutines hanging with no proper exceptions to let me kmow what happened... and channel and context problems in certain use cases), if all the changes will happen soon, it shouldn't be too bad to wait, but as long as coroutines are being called production-ready, they should be treated so, and devs time is precious compared to the 'waste' of documenting things that will change in months time... the rx comparison exists but doesn't include the pitfalls like you said, and channels is also lacking... hard? Is it better for even 100 devs to waste a lot of time, or one to write docs? The feedback will also be from a more educated standpoint, there are a bunch of issues like that on the repo that are just questions based on confusion of how things work...
g
I don’t think that official RxJava docs is good example of documentation. RxJava has a lot of pitfalls and very tricky behaviour and documentation is not really helpful in many cases.
What kind docs is not enough for you now? I agree that some points should be more visible to avoid confusion.
I didn’t mean docs about combining context
@dave08 But original thread started as problem with understanding of context combining
the last few days I spent lots of time with tests and coroutines hanging with no proper exceptions to let me kmow what happened
What is the reason of this problem? Maybe make sense to add this to docs to avoid future problems
I just think that coroutine documentation is pretty good for such young and fast-changing library. But this is my point, that if you had such non-obvious case like you with “hanging” coroutine, would be good to have some document where you could add your case and probably help others to avoid it in the future
d
It hasn't changed for a while (the docs for sure and even the lib has over 88 issues that are standing, a lot because of unsurities in design), I just mentioned this on this thread because this is another confusion point. In #ktor, you can see how @Deactivated User looks actively for any bit of confusion and documents it on the spot, it's also changing I think... someone that would look through all the github issues and put together a knowledge base, and be attentive enough on this channel...
In the end, some of those undecided how to make it and hanging issues in the repo will have a more educated user base to decide on them. Say the new actor model, or the Subscriptions pull requests are nice things that have been hanging for some time... questions on what to change or how to change it...
g
52 of 96 issues are enchancements, 17 unlabeled, 6 API design, 5 integrations with other libraries, 5 “waiting for clarification”, and only 3 docs needed and 5 “question”
I don’t want to say that docs improvements are not needed or docs are perfect, just maybe make sense at least report lack of docs.
d
I haven't done stats like this 🙂 , but I've seen a bunch of issues with confused people... and lack of docs were reported a few times, I think this needs someone a bit more attentive and active on this, people don't report when anyways no docs are going to be made...
g
Maybe if you know such case, just report it or send PR
d
I tried, and PR is hard when you don't know everything yourself... simple smile
I'm not complaining, they're doing great work at JB... but I find that this would be a nice investment...
g
Without feedback about docs is hard to understand what exactly should be improved
I would like to participate btw
But as I said, now is hard to add such tips to coroutine guide, is not the place imo. If some parts of guide are not clear would be good to report an issue, but would be nice to create tips/common pitfalls/faq document. so community could easily contribute some common problems/advices
👍🏼 1
a
The one thing they really need to hammer on is saying that coroutines is just syntactic sugar - it doesn’t magically make ur blocking code non blocking - that was a big stumbling block for how i learned it - only after Andrey explained it to me did i get the true purpose
d
I think a nice way to start, is to start 😄, once people see that docs are moving, they'll be motivated to say when they are lacking.. it happened with #ktor it could happen with #coroutines ....
g
ktor had a lot of big parts of lib completely undocumented, it’s not true or at least not so bad with coroutines. With ktor you always knew which docs is not enought, just because most of pages been empty with “TODO” mark
d
That would be a good idea! To open placeholders for coroutines as unclarities come in, and let people that know the answer try to fill them in. The problem is coroutines is much more complex and someone with a good understanding would have to manage it...
g
Yes, and issue tracker is good place to report. Because authors of the library manage it
2 Views
Open in Slack
PreviousNext
Powered by