I am new to coroutines but I almost without except...

# coroutines

[spand]

I am new to coroutines but I almost without exception end up calling launch and friends without giving the explicit context that I actually intend to. How do you guys avoid this ?

[gildor]

Avoid what?

[gildor]

It's not necessary to pass context explicitly

[gildor]

It's completely fine to use default context for non-blocking coroutines (so if you do not block thread inside of coroutine)

[spand]

Avoid forgetting to pass in the context 🙂 It just seems very error prone to rely on discipline avoid using the default context.. but maybe its just me

[gildor]

What is wrong or error prone with default context?

[gildor]

What kind context would you use instead of default one for non-blocking coroutines?

[gildor]

My point that you can use CommonPool or own custom dispatcher for non-blocking coroutines explicitly, but if you block somewhere you will get the same problems as with default context (CommonPool), so no difference there.
New default dispatcher with shared thread poll will solve some of those problems with accidental blocking:
https://github.com/Kotlin/kotlinx.coroutines/issues/261

But when this will be ready would be better to use default distpatcher instead of CommonPool (depends on final implemwntation, maybe CommonPool will save old behaviour, maybe will use shared thread pool as DefaultDispatcher)

[spand]

Well, in any cases where you want to use an explicit context 😄 In my first day of using coroutines I have needed that in two cases: Inheriting the context for child jobs (so I can cancel them), and injecting a context so that I can substitute with the soon to be released TestCoroutineContext.

[gildor]

I’m not against explicit context, you can use it for many things, child coroutine is probably most common.
But for example explicitly set CommonPool is just useless, it doesn’t prevent any bugs

[gildor]

But in case of parent context or injecting it’s not “explicit context” anymore, because “implicit” version just have different semantics and different behaviour

[spand]

I dont get what you are saying in the last message

[gildor]

😁 Sorry for my strange sentence. I just think that when you use custom context for child coroutine or for testing is not “explicit” it’s “custom”. Because I remember when context was not optional field and everyone just pass CommonPool, and this is not better than “implicit”

[spand]

I have the same issue with many of the jdk methods that take a default timezone, locale, charset and such. Its easy to use them incorrectly and incorrect use results in subtle bugs. I admit I have limited experience with coroutines but I would expect that most calls to launch and friends ought to use their parent context if they are called from another coroutine and only the calls that initiate a graph of coroutines should use these with a default context

[spand]

Ah ok. I get your point on that

[gildor]

I think that call of launch as child coroutine is relatively rare case and usually can be avoided

[gildor]

but of course there are some use cases when it would be helpful

[gildor]

launch and friends

There is only launch, await and withContext, and only launch and await have default context, just because it’s impossible to run them without dispatcher, withContext by default use parent job

[Vsevolod Tolstopyatov [JB]]

Note:
We’re working on deprecating top-level launch and async (and other builders) and making them extensions functions on something like CoroutineContext (actually, on ParentJobHolder, because it’s mainly about parent inheritance rather than about dispatcher).

[Vsevolod Tolstopyatov [JB]]

Currently it’s too easy to “fire-and-forget” coroutine, even though it’s logically bound to Android Activity/WebSocket session etc.

[spand]

Nice. Exactly my thoughts. I noticed elizarov did write something about this in the testcontext PR also. Good to hear its actively being worked on.