You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brpc.apache.org by ji...@apache.org on 2022/10/16 21:18:11 UTC
[incubator-brpc] branch master updated: docs: fix some typos
This is an automated email from the ASF dual-hosted git repository.
jiashunzhu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-brpc.git
The following commit(s) were added to refs/heads/master by this push:
new 8b3a7cd6 docs: fix some typos
new 95a2be1a Merge pull request #1954 from catandcoder/master
8b3a7cd6 is described below
commit 8b3a7cd63aa394c19aa2a4ca474db24521aa9558
Author: cui fliter <im...@gmail.com>
AuthorDate: Sat Oct 15 14:49:18 2022 +0800
docs: fix some typos
Signed-off-by: cui fliter <im...@gmail.com>
---
docs/cn/bvar_c++.md | 2 +-
docs/cn/execution_queue.md | 2 +-
docs/cn/http_client.md | 2 +-
docs/cn/http_service.md | 2 +-
docs/cn/io.md | 2 +-
docs/cn/streaming_rpc.md | 2 +-
docs/en/http_client.md | 2 +-
docs/en/memcache_client.md | 2 +-
docs/en/overview.md | 2 +-
docs/en/status.md | 2 +-
docs/en/streaming_rpc.md | 2 +-
11 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/docs/cn/bvar_c++.md b/docs/cn/bvar_c++.md
index dc5dddd0..478335fe 100644
--- a/docs/cn/bvar_c++.md
+++ b/docs/cn/bvar_c++.md
@@ -259,7 +259,7 @@ dump功能由如下gflags控制：
| bvar_dump_include | "" | Dump bvar matching these wildcards(separated by comma), empty means including all |
| bvar_dump_interval | 10 | Seconds between consecutive dump |
| bvar_dump_prefix | \<app\> | Every dumped name starts with this prefix |
-| bvar_dump_tabs | \<check the code\> | Dump bvar into different tabs according to the filters (seperated by semicolon), format: *(tab_name=wildcards) |
+| bvar_dump_tabs | \<check the code\> | Dump bvar into different tabs according to the filters (separated by semicolon), format: *(tab_name=wildcards) |
当bvar_dump_file不为空时，程序会启动一个后台导出线程以bvar_dump_interval指定的间隔更新bvar_dump_file，其中包含了被bvar_dump_include匹配且不被bvar_dump_exclude匹配的所有bvar。
diff --git a/docs/cn/execution_queue.md b/docs/cn/execution_queue.md
index 6e95ba29..17dcbcfa 100644
--- a/docs/cn/execution_queue.md
+++ b/docs/cn/execution_queue.md
@@ -157,7 +157,7 @@ int execution_queue_execute(ExecutionQueueId<T> id,
// Execute a task with options. e.g
// bthread::execution_queue_execute(queue, task, &bthread::TASK_OPTIONS_URGENT)
// If |options| is NULL, we will use default options (normal task)
-// If |handle| is not NULL, we will assign it with the hanlder of this task.
+// If |handle| is not NULL, we will assign it with the handler of this task.
template <typename T>
int execution_queue_execute(ExecutionQueueId<T> id,
typename butil::add_const_reference<T>::type task,
diff --git a/docs/cn/http_client.md b/docs/cn/http_client.md
index 957ca136..66d3292c 100644
--- a/docs/cn/http_client.md
+++ b/docs/cn/http_client.md
@@ -222,7 +222,7 @@ brpc client支持在读取完body前就结束RPC，让用户在RPC结束后再
class ProgressiveReader {
public:
// Called when one part was read.
- // Error returned is treated as *permenant* and the socket where the
+ // Error returned is treated as *permanent* and the socket where the
// data was read will be closed.
// A temporary error may be handled by blocking this function, which
// may block the HTTP parsing on the socket.
diff --git a/docs/cn/http_service.md b/docs/cn/http_service.md
index 6aaa4b88..c8945eb1 100644
--- a/docs/cn/http_service.md
+++ b/docs/cn/http_service.md
@@ -17,7 +17,7 @@ brpc中http和h2的编程接口基本没有区别。除非特殊说明，所有
## 前缀为/ServiceName/MethodName
-定义一个service名为ServiceName(不包含package名), method名为MethodName的pb服务，且让request和reponse定义为空，则该服务默认在/ServiceName/MethodName上提供http/h2服务。
+定义一个service名为ServiceName(不包含package名), method名为MethodName的pb服务，且让request和response定义为空，则该服务默认在/ServiceName/MethodName上提供http/h2服务。
request和response可为空是因为数据都在Controller中：
diff --git a/docs/cn/io.md b/docs/cn/io.md
index e695d272..f2e352fe 100644
--- a/docs/cn/io.md
+++ b/docs/cn/io.md
@@ -40,7 +40,7 @@ linux一般使用non-blocking IO提高IO并发度。当IO并发度很低时，no
存储SocketUniquePtr还是SocketId取决于是否需要强引用。像Controller贯穿了RPC的整个流程，和Socket中的数据有大量交互，它存放的是SocketUniquePtr。epoll主要是提醒对应fd上发生了事件，如果Socket回收了，那这个事件是可有可无的，所以它存放了SocketId。
-由于SocketUniquePtr只要有效，其中的数据就不会变，这个机制使用户不用关心麻烦的race conditon和ABA problem，可以放心地对共享的fd进行操作。这种方法也规避了隐式的引用计数，内存的ownership明确，程序的质量有很好的保证。brpc中有大量的SocketUniquePtr和SocketId，它们确实简化了我们的开发。
+由于SocketUniquePtr只要有效，其中的数据就不会变，这个机制使用户不用关心麻烦的race condition和ABA problem，可以放心地对共享的fd进行操作。这种方法也规避了隐式的引用计数，内存的ownership明确，程序的质量有很好的保证。brpc中有大量的SocketUniquePtr和SocketId，它们确实简化了我们的开发。
事实上，Socket不仅仅用于管理原生的fd，它也被用来管理其他资源。比如SelectiveChannel中的每个Sub Channel都被置入了一个Socket中，这样SelectiveChannel可以像普通channel选择下游server那样选择一个Sub Channel进行发送。这个假Socket甚至还实现了健康检查。Streaming RPC也使用了Socket以复用wait-free的写出过程。
diff --git a/docs/cn/streaming_rpc.md b/docs/cn/streaming_rpc.md
index 987ce37b..14a44c22 100644
--- a/docs/cn/streaming_rpc.md
+++ b/docs/cn/streaming_rpc.md
@@ -47,7 +47,7 @@ struct StreamOptions
size_t messages_in_batch;
// Handle input message, if handler is NULL, the remote side is not allowd to
- // write any message, who will get EBADF on writting
+ // write any message, who will get EBADF on writing
// default: NULL
StreamInputHandler* handler;
};
diff --git a/docs/en/http_client.md b/docs/en/http_client.md
index fb41a6b4..a6e0e34a 100644
--- a/docs/en/http_client.md
+++ b/docs/en/http_client.md
@@ -227,7 +227,7 @@ How to use:
class ProgressiveReader {
public:
// Called when one part was read.
- // Error returned is treated as *permenant* and the socket where the
+ // Error returned is treated as *permanent* and the socket where the
// data was read will be closed.
// A temporary error may be handled by blocking this function, which
// may block the HTTP parsing on the socket.
diff --git a/docs/en/memcache_client.md b/docs/en/memcache_client.md
index decca09d..4f9a4918 100644
--- a/docs/en/memcache_client.md
+++ b/docs/en/memcache_client.md
@@ -58,7 +58,7 @@ Notes on above code:
- The class of the request must be `MemcacheRequest`, response must be `MemcacheResponse`, otherwise `CallMethod` fails. `stub` is not necessary, just call `channel.CallMethod` with `method` to NULL.
- Call `request.XXX()` to add an operation, where `XXX` is `Set` in this example. Multiple operations inside a request are sent to a memcached server together (often referred to as "pipeline mode").
- call `response.PopXXX()` to pop result of an operation from the response, where `XXX` is `Set` in this example. true is returned on success, and false otherwise in which case use `response.LastError()` to get the error message. `XXX` must match the corresponding operation in the request, otherwise the pop is rejected. In above example, a `PopGet` would fail with the error message of "not a GET response".
-- Results of `Pop` are independent from the RPC result. Even if "a value cannot be put into the memcached", the RPC may still be successful. RPC failure means things like broken connection, timeout etc. If the business logic requires the memcache operations to be succesful, you should test successfulness of both RPC and `PopXXX`.
+- Results of `Pop` are independent from the RPC result. Even if "a value cannot be put into the memcached", the RPC may still be successful. RPC failure means things like broken connection, timeout etc. If the business logic requires the memcache operations to be successful, you should test successfulness of both RPC and `PopXXX`.
Supported operations currently:
diff --git a/docs/en/overview.md b/docs/en/overview.md
index c26909cf..32185e0b 100644
--- a/docs/en/overview.md
+++ b/docs/en/overview.md
@@ -83,7 +83,7 @@ brpc pays special attentions to development and maintenance efficency, you can [
Although almost all RPC implementations claim that they're "high-performant", the numbers are probably just numbers. Being really high-performant in different scenarios is difficult. To unify communication infra inside Baidu, brpc goes much deeper at performance than other implementations.
-* Reading and parsing requests from different clients is fully parallelized and users don't need to distinguish between "IO-threads" and "Processing-threads". Other implementations probably have "IO-threads" and "Processing-threads" and hash file descriptors(fd) into IO-threads. When a IO-thread handles one of its fds, other fds in the thread can't be handled. If a message is large, other fds are significantly delayed. Although different IO-threads run in parallel, you won't have many IO [...]
+* Reading and parsing requests from different clients is fully parallelized and users don't need to distinguish between "IO-threads" and "Processing-threads". Other implementations probably have "IO-threads" and "Processing-threads" and hash file descriptors(fd) into IO-threads. When a IO-thread handles one of its fds, other fds in the thread can't be handled. If a message is large, other fds are significantly delayed. Although different IO-threads run in parallel, you won't have many IO [...]
* Writing into one fd and multiple fds is highly concurrent. When multiple threads write into the same fd (common for multiplexed connections), the first thread directly writes in-place and other threads submit their write requests in [wait-free](https://en.wikipedia.org/wiki/Non-blocking_algorithm#Wait-freedom) manner. One fd can be written into 5,000,000 16-byte messages per second by a couple of highly-contended threads. More details can be found [here](io.md#sending-messages).
* Minimal locks. High-QPS services can utilize all CPU power on the machine. For example, [creating bthreads](../cn/memory_management.md) for processing requests, [setting up timeout](../cn/timer_keeping.md), [finding RPC contexts](../cn/bthread_id.md) according to response, [recording performance counters](bvar.md) are all highly concurrent. Users see very few contentions (via [contention profiler](../cn/contention_profiler.md)) caused by RPC framework even if the service runs at 500,000+ QPS.
* Server adjusts thread number according to load. Traditional implementations set number of threads according to latency to avoid limiting the throughput. brpc creates a new [bthread](../cn/bthread.md) for each request and ends the bthread when the request is done, which automatically adjusts thread number according to load.
diff --git a/docs/en/status.md b/docs/en/status.md
index 69a6a4e0..1d02c871 100644
--- a/docs/en/status.md
+++ b/docs/en/status.md
@@ -10,7 +10,7 @@ Meanings of the fields above:
- **connection_count**: number of connections to the server from clients, not including number of outward connections which are displayed at /vars/rpc_channel_connection_count.
- **example.EchoService**: Full name of the service, including the package name defined in proto.
- **Echo (EchoRequest) returns (EchoResponse)**: Signature of the method. A service can have multiple methods. Click links on request/response to see schemes of the protobuf messages.
-- **count**: Number of requests that are succesfully processed.
+- **count**: Number of requests that are successfully processed.
- **error**: Number of requests that are failed to process.
- **latency**: average latency in recent *60s/60m/24h/30d* from *right to left* on html, average latency in recent 10s(by default, specified by [-bvar_dump_interval](http://brpc.baidu.com:8765/flags/bvar_dump_interval)) on plain texts.
- **latency_percentiles**: 80%, 90%, 99%, 99.9% percentiles of latency in 10 seconds(specified by[-bvar_dump_interval](http://brpc.baidu.com:8765/flags/bvar_dump_interval)). Curves with historical values are shown on html.
diff --git a/docs/en/streaming_rpc.md b/docs/en/streaming_rpc.md
index 8ea32e23..58ee7a96 100644
--- a/docs/en/streaming_rpc.md
+++ b/docs/en/streaming_rpc.md
@@ -47,7 +47,7 @@ struct StreamOptions
size_t messages_in_batch;
// Handle input message, if handler is NULL, the remote side is not allowd to
- // write any message, who will get EBADF on writting
+ // write any message, who will get EBADF on writing
// default: NULL
StreamInputHandler* handler;
};
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org