update tutorials 08,09,12 English Version (#79)

Author: holmes1412

docs/en/tutorial-08-matrix_multiply.md

@@ -4,15 +4,15 @@
 
 [tutorial-08-matrix\_multiply.cc](../tutorial/tutorial-08-matrix_multiply.cc)
 
-# About matrix_multiply
+# About matrix\_multiply
 
-The program multiplies two matrices and displays the results on the console.   
+The program multiplies two matrices and prints the results on the screen.   
 The main purpose of the example is to show how to implement a user-defined CPU computing task.
 
 # About computing tasks
 
-A computing task has three arguments: INPUT, OUTPUT, and routine.   
-INPUT and OUTPUT are two template parameters that can hold any type, and a routine is the process from INPUT to OUTPUT. A computing task is defined as follows:
+You need to provide three types of basic information when you define a computer task: INPUT, OUTPUT, and routine.   
+INPUT and OUTPUT are two template parameters, which can be of any type. routine means the process from INPUT to OUTPUT, which is defined as follows:
 
 ~~~cpp
 template <class INPUT, class OUTPUT>
@@ -24,8 +24,8 @@ class __WFThreadTask
 };
 ~~~
 
-You can see that routine is a simple computing process from INPUT to OUTPUT. The INPUT pointer is not necessarily be const, but you can pass const INPUT \*.   
-For example, to implement a task that adds two numbers, you can use the follow code:
+It can be seen that routine is a simple computing process from INPUT to OUTPUT. The INPUT pointer is not necessarily be const, but you can also pass the function of const INPUT \*.   
+For example, to implement an adding task, you can:
 
 ~~~cpp
 struct add_input
@@ -47,7 +47,7 @@ void add_routine(const add_input *input, add_output *output)
 typedef WFThreadTask<add_input, add_output> add_task;
 ~~~
 
-In matrix multiplication, the input includes two matrices and the output is one matrix. They are defined as follows:
+In the example of matrix multiplication, the input is two matrices and the output is one matrix. They are defined as follows:
 
 ~~~cpp
 namespace algorithm
@@ -76,12 +76,12 @@ void matrix_multiply(const MMInput *in, MMOutput *out)
 }
 ~~~
 
-As the input matrices may be incompatible in matrix multiplication, there is an error field in the output to indicate that error.
+As the input matrices may be illegal in matrix multiplication, so there is an error field in the output to indicate errors.
 
 # Generating computing tasks
 
-After you define the types of input and output and the algorithm process, you can use WFThreadTaskFactory to generate a computing task.   
-In [WFTaskFactory.h](../src/factory/WFTaskFactory.h), the calculation factory is defined as follows:
+After you define the types of input and output and the algorithm process, you can use  WFThreadTaskFactory  to generate a computing task.   
+In [WFTaskFactory.h](../src/factory/WFTaskFactory.h), the computing task factory is defined as follows:
 
 ~~~cpp
 template <class INPUT, class OUTPUT>
@@ -98,9 +98,9 @@ public:
 };
 ~~~
 
-Slightly different from the previous network factory class or the algorithm factory class, this class requires two template parameters: INPUT and OUTPUT.   
-queue\_name is explained in the previous example. routine is the computing process, and the callback means the callback of the function.   
-In the example, there is a call:
+Slightly different from the previous network factory class or the algorithm factory class, this factory requires two template parameters: INPUT and OUTPUT.   
+queue\_name is explained in the previous example. routine is the computation process, and callback means the callback.   
+In our example, we see this call:
 
 ~~~cpp
 using MMTask = WFThreadTask<algorithm::MMInput,
@@ -123,7 +123,7 @@ int main()
 }
 ~~~
 
-After the task is generated, you can use **get\_input()** interface to get the pointer of the input data. This is similar to the **get\_req()** in a network task.   
+After the task is generated, use **get\_input()** interface to get the pointer of the input data. This is similar to the **get\_req()** in a network task.   
 The start and the end of a task is the same as those of a network task. Similarly, the callback is very simple:
 
 ~~~cpp
@@ -148,22 +148,22 @@ void callback(MMTask *task)     // MMtask = WFThreadTask<MMInput, MMOutput>
 }
 ~~~
 
-You can ignore the possibility of failure in ordinary computing tasks, and the end state is always SUCCESS.   
+You can ignore the the possibility of failure in the ordinary computing tasks, and the end state is always SUCCESS.   
 The callback simply prints out the input and the output. If the input data are illegal, the error will be printed out.
 
 # Symmetry of the algorithm and the protocol
 
 In our system, algorithms and protocols are highly symmetrical on a very abstract level.   
-There are thread tasks with user-defined algorithms, and obviously there are network tasks with user-defined protocols.   
-A user-defined algorithm requires a user to provide the  procedure for algorithm implementation, and a user-defined protocol requires a user to provide the procedures for serialization and deserialization. You can see an introduction in [Simple client/server based on user-defined protocols](./tutorial-10-user_defined_protocol.md)   
-For user-defined algorithms and user-defined protocols, both algorithms and protocols must be very pure and have single responsibility.   
-For example, an algorithm is just a conversion procedure from INPUT to OUPUT, and the algorithm does not care about the existence of task, series, and etc.   
-The implementation of an HTTP protocol only cares about serialization and deserialization, and does not need to care about the task. Instead, an HTTP task refers to the HTTP protocol.
+There are thread tasks with user-defined algorithms,  obviously there are network tasks with user-defined protocols.   
+A user-defined algorithm requires the user to provide the algorithm procedure, and a user-defined protocol requires the user to provide the procedure of serialization and deserialization. You can see an introduction in [Simple client/server based on user-defined protocols](./tutorial-10-user_defined_protocol.md)   
+For the user-defined algorithms and the user-defined protocols, both must be very pure .   
+For example, an algorithm is just a conversion procedure from INPUT to OUPUT, and the algorithm does not know the existence of task, series, etc.   
+The implementation of an HTTP protocol only cares about serialization and deserialization, and does not need to care about the task definition. Instead, the HTTP protocol is referred to in an http task.
 
-# Compositionality of thread tasks and network tasks
+# Composite features of thread tasks and network tasks
 
 In this example, we use WFThreadTaskFactory to build a thread task. This is the simplest way to get a computing task, and it is sufficient in most cases.   
 Similarly, you can simply define a server and a client with a user-defined protocol.   
-However, in the previous example, we use the algorithm factory to generate a parallel sorting task, which is obviously not possible with a routine.   
+However, in the previous example, we can use the algorithm factory to generate a parallel sorting task, which is obviously not possible with a routine.   
 For a network task, such as a Kafka task, interactions with several machines may be required to get results, but it is completely transparent to users.   
-Therefore, our tasks are composite. If you use our framework skillfully, you can design a lot of composite  components.
+Therefore, our tasks are composite. If you use our framework skillfully, you can design many composite components.

docs/en/tutorial-09-http_file_server.md

@@ -1,4 +1,4 @@
-# HTTP server with file IO: http\_file\_server
+# Http server with file IO: http\_file\_server
 
 # Sample code
 
@@ -7,12 +7,12 @@
 # About http\_file\_server
 
 http\_file\_server is a web server. You can start a web server after specifying the startup port and the root path (the default setting is the current path).   
-You can also start an HTTPS web server after specifying both a certificate file and a key file in PEM format.   
-This article mainly demonstrates how to use disk IO tasks. In the Linux system, we use the **aio** interface in the kernel of Linux, and the file reading is completely asynchronous.
+You can also specify a certificate file and a key file in PEM format to start an HTTPS web server.   
+The program mainly demonstrates how to use disk IO tasks. In the Linux system, we use the aio interface in the kernel of Linux, and the file reading is completely asynchronous.
 
 # Starting a server
 
-Server startup procedure is almost the same as that of an echo server or an HTTP proxy, but here you can start an SSL server:
+For starting a server, the steps are almost the same as those when starting an echo server or an HTTP proxy. There is one more way to start an SSL server here:
 
 ~~~cpp
 class WFServerBase
@@ -23,7 +23,7 @@ class WFServerBase
 };
 ~~~
 
-In other words, you can specify a cert file and a key file in PEM format and then start an SSL server.   
+In other words, you can specify a cert file and a key file in PEM format to start an SSL server.   
 In addition, when you define a server, you can use **std::bind()** to bind a root parameter to the process. The root parameter means the root path of the service.
 
 ~~~cpp
@@ -47,7 +47,7 @@ int main(int argc, char *argv[])
 # Handling requests
 
 Similar to http\_proxy, no threads are occupied in file reading. Instead, an asynchronous task is generated to read files, and a reply to the request is generated after the reading is completed.   
-Please note again that the complete reply data should be read into the memory before the reply is sent. Therefore, it is not suitable for transferring large files.
+Please note again that the complete reply data should be read into the memory before the reply message is sent. Therefore, it is not suitable for transferring very large files.
 
 ~~~cpp
 void process(WFHttpTask *server_task, const char *root)
@@ -79,7 +79,7 @@ void process(WFHttpTask *server_task, const char *root)
 }
 ~~~
 
-Unlike http\_proxy that generates a new HTTP client task, here a **pread** task is generated by the factory.   
+Unlike http\_proxy that generates a new HTTP client task, here a pread task is generated by the factory.   
 [WFAlgoTaskFactory.h](../src/factory/WFTaskFactory.h) contains the definitions of relevant interfaces.
 
 ~~~cpp
@@ -109,9 +109,9 @@ public:
 };
 ~~~
 
-Both **pread** and **pwrite** return WFFileIOTask. The same principle also applies to **sort** and **psort**, and to client tasks and server tasks.    
-In addition to these two interfaces, **preadv** and **pwritev** return WFFileVIOTask; **fsync** and **fdsync** return WFFileSyncTask. You can see the details in the header file.   
-Currently, our interface requires users to open and close **fd** by themselves. We are developing a set of file management interfaces. In the future, users only need to pass file names, which is more friendly to cross-platform applications.   
+Both pread and pwrite return WFFileIOTask. We do not distinguish between sort and psort, and we do not distinguish between client and server task. They all follow the same principle.   
+In addition to these two interfaces, preadv and pwritev return WFFileVIOTask; fsync and fdsync return WFFileSyncTask. You can see the details in the header file.   
+Currently, our interface requires users to open and close fd by themselves. We are developing a set of file management interfaces. In the future, users only need to pass file names, which is more friendly to cross-platform applications.   
 The example uses the user\_data field of the task to save the global data of the service. For larger services, we recommend to use series context. You can see the [proxy examples](../tutorial/tutorial-05-http_proxy.cc) for details.
 
 # Handling file reading results
@@ -136,18 +136,18 @@ void pread_callback(WFFileIOTask *task)
 }
 ~~~
 
-You can use **get\_args()** of the file task to get the input parameters. Here it is a FileIOArgs struct.   
-And you can use **get\_retval()** to get the return value of the operation. If ret < 0, the task fails. Otherwise, the ret is the size of the data.   
+Use **get\_args()** of the file task to get the input parameters. Here it is a FileIOArgs struct.   
+Use **get\_retval()** to get the return value of the operation. If ret < 0, the task fails. Otherwise, the ret is the size of the read data.   
 In the file task, ret < 0 and task->get\_state()! = WFT\_STATE\_SUCCESS are completely equivalent.   
-The memory of the buf is managed by the user. You can use  **append\_output\_body\_nocopy()** to pass that memory to resp.   
-After the reply is completed, the system will **free()** this block of memory with this line in the process:   
+The memory of the buf domain is managed by ourselves. You can use  **append\_output\_body\_nocopy()** to pass that memory to resp.   
+After the reply is completed, we will **free()** this block of memory with this line in the process:   
 server\_task->set\_callback(\[](WFHttpTask \*t){ free(t->user\_data); });
 
-# About the implementation of the asynchronous file IO
+# About the implementation of the file IO
 
-Linux operating system supports a set of asynchronous IO calls with high efficiency and very little CPU occupation. If you use our framework in a Linux system, this set of interfaces are used by default.   
-We have implemented a set of posix aio interfaces to support other UNIX systems, and use the **sigevent** notification method of threads, but it is no longer in use because of its low efficiency.   
-Currently, for non-Linux systems, asynchronous IO is always realized through multithreading. When an IO task arrives, a thread is created in real time to execute the IO task, and then a callback is used to return to the handler thread pool.   
-Multi-threaded IO is also the only choice in macOS, because macOS does not have good **sigevent** support and posix aio does not work in macOS.   
-Multithreaded IO does not support preadv and pwritev tasks. When these two tasks are created and run, you will get an ENOSYS error in the callback.   
-Some UNIX systems do not support fdatasync. In this case, an fdsync task is equivalent to an fsync task.
+Linux operating system supports a set of asynchronous IO system calls with high efficiency and very little CPU occupation. If you use our framework in a Linux system, this set of interfaces are used by default.   
+We have implemented a set of posix aio interfaces to support other UNIX systems, and used the sigevent notification method of threads, but it is no longer in use because of its low efficiency.   
+Currently, for non-Linux systems, asynchronous IO is always simulated by multi-threading. When an IO task arrives, a thread is created in real time to execute IO tasks, and then a callback is used to return to the handler thread pool.   
+Multi-threaded IO is also the only choice in macOS, because macOS does not have good sigevent support and posix aio will not work in macOS.   
+Multi-threaded IO does not support preadv and pwritev tasks. When these two tasks are created and run, you will get an ENOSYS error in the callback.   
+Some UNIX systems do not support fdatasync. In this case, an fdsync task is equivalent to an fsync task.