From 6c0bb60930e042637bc9afe1b22fac6b73f10783 Mon Sep 17 00:00:00 2001 From: Ying Li Date: Tue, 24 Jun 2025 21:44:25 +0900 Subject: [PATCH] minor fix for doc --- docs/topics/coroutines-and-channels.md | 28 +++++++++++++------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/topics/coroutines-and-channels.md b/docs/topics/coroutines-and-channels.md index 45081dc8bc..8bb576a717 100644 --- a/docs/topics/coroutines-and-channels.md +++ b/docs/topics/coroutines-and-channels.md @@ -50,7 +50,7 @@ Generate a new GitHub token to use the GitHub API with [your account](https://gi ### Run the code -The program loads the contributors for all of the repositories under the given organization (named “kotlin” by default). +The program loads the contributors for all of the repositories under the given organization (named "kotlin" by default). Later you'll add logic to sort the users by the number of their contributions. 1. Open the `src/contributors/main.kt` file and run the `main()` function. You'll see the following window: @@ -264,7 +264,7 @@ which uses callbacks instead of blocking calls. happens on the main UI thread (AWT event dispatching thread). However, if you try to load the contributors via the `BACKGROUND` option, you can see that the list is updated but -nothing changes. +nothing changes in UI. ### Task 2 @@ -570,7 +570,7 @@ The coroutine resumes only after the corresponding response is received: While the response is waiting to be received, the thread is free to be occupied by other tasks. The UI stays responsive, despite all the requests taking place on the main UI thread: -1. Run the program using the _SUSPEND_ option. The log confirms that all of the requests are sent to the main UI thread: +1. Run the program using the _SUSPEND_ option. The log confirms that all of the requests are sent from the main UI thread: ```text 2538 [AWT-EventQueue-0 @coroutine#1] INFO Contributors - kotlin: loaded 30 repos @@ -854,7 +854,7 @@ corresponding to the parent coroutine. It's possible to create a new scope without starting a new coroutine, by using the `coroutineScope` function. To start new coroutines in a structured way inside a `suspend` function without access to the outer scope, you can create a new coroutine scope that automatically becomes a child of the outer scope that this `suspend` function is called from. -`loadContributorsConcurrent()`is a good example. +`loadContributorsConcurrent()` is a good example. You can also start a new coroutine from the global scope using `GlobalScope.async` or `GlobalScope.launch`. This will create a top-level "independent" coroutine. @@ -1165,7 +1165,7 @@ consumers. Once an element is handled, it is immediately removed from the channe You can think of a channel as similar to a collection of elements, or more precisely, a queue, in which elements are added to one end and received from the other. However, there's an important difference: unlike collections, even in their -synchronized versions, a channel can _suspend_ `send()`and `receive()` operations. This happens when the channel is empty +synchronized versions, a channel can _suspend_ `send()` and `receive()` operations. This happens when the channel is empty or full. The channel can be full if the channel size has an upper bound. `Channel` is represented by three different interfaces: `SendChannel`, `ReceiveChannel`, and `Channel`, with the latter @@ -1195,7 +1195,7 @@ For all of the channel types, the `receive()` call behaves similarly: it receive otherwise, it is suspended. - +

An unlimited channel is the closest analog to a queue: producers can send elements to this channel and it will keep growing indefinitely. The send() call will never be suspended. If the program runs out of memory, you'll get an OutOfMemoryException. @@ -1203,13 +1203,13 @@ The difference between an unlimited channel and a queue is that when a consumer it becomes suspended until some new elements are sent.

Unlimited channel - +

The size of a buffered channel is constrained by the specified number. Producers can send elements to this channel until the size limit is reached. All of the elements are internally stored. -When the channel is full, the next `send` call on it is suspended until more free space becomes available.

+When the channel is full, the next send() call on it is suspended until more free space becomes available.

Buffered channel - +

The "Rendezvous" channel is a channel without a buffer, the same as a buffered channel with zero size. One of the functions (send() or receive()) is always suspended until the other is called.

If the send() function is called and there's no suspended receive() call ready to process the element, then send() @@ -1219,7 +1219,7 @@ suspended send() call ready to send the element, the receive( should "meet on time".

Rendezvous channel - +

A new element sent to the conflated channel will overwrite the previously sent element, so the receiver will always get only the latest element. The send() call is never suspended.

Conflated channel @@ -1481,10 +1481,10 @@ In the project corresponding to this tutorial, the compiler argument has already Refactor the following tests in `tests/tasks/` to use virtual time instead of real time: -* Request4SuspendKtTest.kt -* Request5ConcurrentKtTest.kt -* Request6ProgressKtTest.kt -* Request7ChannelsKtTest.kt +* `Request4SuspendKtTest.kt` +* `Request5ConcurrentKtTest.kt` +* `Request6ProgressKtTest.kt` +* `Request7ChannelsKtTest.kt` Compare the total running times before and after applying your refactoring.