Rooba
/
drogon
mirror of https://github.com/drogonframework/drogon.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Sync english doc with chinese (#22)

Martin Chang 2021-12-11 22:07:18 +08:00 committed by GitHub
parent a8d85dbdce
commit c207a200c0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
ENG-FAQ-1-Understanding-drogon-threading-model.md

@ -43,7 +43,12 @@ The thread hierarchy looks like this
<thread 1> <thread 2> <thread ...>
```
The number of worker loops depends on numerous variables. Namely, how many threads are specified for the HTTP server, how many non-fast DB and NoSQL connections are created - we'll get to fast vs non-fast connections later. Just know that drogon has more threads than just the HTTP server threads. Each event loop is essentally a task queue. You can submit task to run on the a loop from any other threads. Task submitting is totally lock free (thanks to lock free data structure!) and won't cause data race in all circumstances. They process tasks one-by-one and goes to sleep when there's nothing to do. Thus tasks have a well-defined order of execution. But also, tasks that's queued after a huge, long running task gets delayed.
The number of worker loops depends on numerous variables. Namely, how many threads are specified for the HTTP server, how many non-fast DB and NoSQL connections are created - we'll get to fast vs non-fast connections later. Just know that drogon has more threads than just the HTTP server threads. Each event loop is essentally a task queue with the following funcionality.
* Reads tasks from a test queue and execute them. You can submit task to run on the a loop from any other threads. Task submitting is totally lock free (thanks to lock free data structure!) and won't cause data race in all circumstances. Event loops process tasks one-by-one. Thus tasks have a well-defined order of execution. But also, tasks that's queued after a huge, long running task gets delayed.
* Listen to and dispatch network events that it manages
* Execue timers when they timeout (usually created by the user)
When non of the above is happning. The event loop/thread blocks and waits for them.
```cpp
// queuing two tasks on the main loop