I am new to coroutines but I almost without exception end up

Question

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 · Answer

Avoid what

gildor · Answer

It s not necessary to pass context explicitly

gildor · Answer

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

spand · Answer

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

gildor · Answer

What is wrong or error prone with default context

gildor · Answer

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

gildor · Answer

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 · Answer

Well in any cases where you want to use an explicit context smile 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 · Answer

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 · Answer

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 · Answer

I dont get what you are saying in the last message

gildor · Answer

grin 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 · Answer

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 · Answer

Ah ok I get your point on that

gildor · Answer

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

gildor · Answer

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

gildor · Answer

gt `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] · Answer

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] · Answer

Currently it s too easy to fire and forget coroutine even though it s logically bound to Android Activity WebSocket session etc

spand · Answer

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