Dispatchers.Default is not installed in coroutine builders when there is no ContinuationInterceptor in native

[whyoleg]

Describe the bug

When using one of the coroutine builders (like launch) if there is no ContinuationInterceptor/CoroutineDispatcher in coroutineContext coroutine should start on Dispatchers.Default as specified in documentation of: Dispatchers.Default, CoroutineScope.newCoroutineContext (which is used under the hood of coroutine builders) and in CoroutineScope.launch itself.

This contract is implemented in actual implementations of CoroutineScope.newCoroutineContext for all platforms (jvm, js, wasmJs) except native, where single-threaded DefaultExecutor is used instead.

Provide a Reproducer

In following example on jvm, js, wasmJs the same dispatcher will be printed (it's name depends on target, but it is Dispatchers.Default`), but on native dispatchers are different:

val job = Job()
val scope = CoroutineScope(job) // no dispatcher provided
scope.launch(Dispatchers.Default) {
    println("default=${coroutineContext[ContinuationInterceptor]}")
}
scope.launch {
    println("empty=${coroutineContext[ContinuationInterceptor]}")
}
job.complete()
job.join()

At my side when running test on macosArm64:

empty=DefaultExecutor@2c70160
default=DarwinGlobalQueueDispatcher@2c30410

Expected behaviour

Dispatchers.Default should be installed on native.
I found this issue during running some tests, after refactoring tests execution time was increased. I had no idea why, but then when I checked dispatcher in some test and found that it's different - just because before it was just EmptyCoroutineContext but now it's Dispatchers.Default`.

Note: test execution time become like several times slower when using Dispatchers.Default - not sure if it's expected or not...

[dkhalanskyjb]

This looks like it's an overlooked artifact of the time the Native implementation was single-threaded.

Note: test execution time become like several times slower when using Dispatchers.Default - not sure if it's expected or not...

On Apple targets, we use our own implementation of scheduling on top of a native thread for DefaultDelay, but delegate to Apple's event queue for Dispatchers.Default. This could be the reason.

[whyoleg]

Are you willing to accept PR for this? This looks rather straightforward from first look.

[dkhalanskyjb]

Sure, please go ahead.