vieter-v
/
v
2
0
Fork 0
Code Issues Pull Requests Releases Activity

doc: change word coroutine to thread (#13308)

pull/13311/head
kahsa 2022-01-28 20:17:36 +09:00 committed by GitHub
parent 71d98717dc
commit 61d28c8a8c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/docs.md
View File

@ -3503,7 +3503,7 @@ fn main() {
``` ```
### Channels ### Channels
Channels are the preferred way to communicate between coroutines. V's channels work basically like Channels are the preferred way to communicate between threads. V's channels work basically like
those in Go. You can push objects into a channel on one end and pop objects from the other end. those in Go. You can push objects into a channel on one end and pop objects from the other end.
Channels can be buffered or unbuffered and it is possible to `select` from multiple channels. Channels can be buffered or unbuffered and it is possible to `select` from multiple channels.
@ -3517,7 +3517,7 @@ ch2 := chan f64{cap: 100} // buffer length 100
``` ```
Channels do not have to be declared as `mut`. The buffer length is not part of the type but Channels do not have to be declared as `mut`. The buffer length is not part of the type but
a field of the individual channel object. Channels can be passed to coroutines like normal a field of the individual channel object. Channels can be passed to threads like normal
variables: variables:
```v ```v
@ -3669,8 +3669,8 @@ and [Channel Select](#channel-select) above).
### Shared Objects ### Shared Objects
Data can be exchanged between a coroutine and the calling thread via a shared variable. Data can be exchanged between a thread and the calling thread via a shared variable.
Such variables should be created as `shared` and passed to the coroutine as such, too. Such variables should be created as `shared` and passed to the thread as such, too.
The underlying `struct` contains a hidden *mutex* that allows locking concurrent access The underlying `struct` contains a hidden *mutex* that allows locking concurrent access
using `rlock` for read-only and `lock` for read/write access. using `rlock` for read-only and `lock` for read/write access.