When creating a new job, it should be easier (default) to create child instead of a new root job

When creating a new Job, the simplest way to do this, and the way most people do it by default is with Job() or SupervisorJob(). However, in most cases what is actually intended is to create a job that is a child of some context or scope. The current state of things makes it really easy to accidentally create a job that breaks out of the hierarchy, which can lead to leaks of coroutines and exceptions, and broken cancellation.

A simple extension function could improve things:

fun CoroutineScope.createJob(): Job = Job(parent = coroutineContext[Job])
fun CoroutineScope.createSupervisorJob(): SupervisorJob = SupervisorJob(parent = coroutineContext[Job])

[zach-klippenstein]

That binding API looks really nice for (1).

My main use case is (2) in your list however. I’m working on a library that uses Jobs under the hood to scope and cancel concurrent work (effectively a hierarchical worker pool). The work is configured in a tree, and so we create a parallel tree of Jobs. Multiple coroutines may be started later using that job as the parent. We’re creating Jobs explicitly, and not as part of an immediate launch or other new coroutine, so I don’t think this binding approach, as described above, wouldn’t solve my use case.

[qwwdfsad]

There was an attempt to add such helpers in #688. We decided to postpone it because creating a child out of thin air is a bit dangerous. For example, the following code

launch {
    childJob() // leftover after refactoring
}.join()

never completes because childJob will never be completed and without a proper debugger it may be really hard to pin down the problem.

Though writing something like SupervisorJob(coroutineContext[Job]) is not the best experience as well. We want to prototype #1406 to address this issue, for example, instead of

scope.launch(SupervisorJob(coroutineContext[Job])) {}

we will provide a flexible “BindJob” (name TBD, just to show the idea):

scope.launch(Bind(mode = Supervising)) {}
// or, TBD
scope.launch(Bind.Supervising)

Bind(mode = Supervising) knows how to bind itself as a supervising job between a parent scope and child job (launch).

It would be really helpful if you could elaborate on why you need such extensions because they have multiple use-cases:

1. Launching a child with a specific cancellation mode (launch(createSupervisorJob))
2. Creating an intermediate child in the hierarchy with multiple children:

fun createSubFragment() {
   val fragment = Fragment(createChildJob()) // Will be used as a field in the fragment
}

1. …probably something else 😃

Understanding the most common patterns will help us a lot in designing the best possible solution in #1406