mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-15 01:12:56 +00:00
0b14fdb078
Reorganize existing READMEs and other documentation files into mdbook format. The resulting Table of Contents is a mix of placeholders for docs that we should write, and documentation files that we already had, dropped into the most appropriate place. Update the Pageserver overview diagram. Add sections on thread management and WAL redo processes. Add all the RFCs to the mdbook Table of Content too. Per github issue #1979
27 lines
1.1 KiB
Markdown
27 lines
1.1 KiB
Markdown
## Thread management
|
|
|
|
Each thread in the system is tracked by the `thread_mgr` module. It
|
|
maintains a registry of threads, and which tenant or timeline they are
|
|
operating on. This is used for safe shutdown of a tenant, or the whole
|
|
system.
|
|
|
|
### Handling shutdown
|
|
|
|
When a tenant or timeline is deleted, we need to shut down all threads
|
|
operating on it, before deleting the data on disk. A thread registered
|
|
in the thread registry can check if it has been requested to shut down,
|
|
by calling `is_shutdown_requested()`. For async operations, there's also
|
|
a `shudown_watcher()` async task that can be used to wake up on shutdown.
|
|
|
|
### Sync vs async
|
|
|
|
The primary programming model in the page server is synchronous,
|
|
blocking code. However, there are some places where async code is
|
|
used. Be very careful when mixing sync and async code.
|
|
|
|
Async is primarily used to wait for incoming data on network
|
|
connections. For example, all WAL receivers have a shared thread pool,
|
|
with one async Task for each connection. Once a piece of WAL has been
|
|
received from the network, the thread calls the blocking functions in
|
|
the Repository to process the WAL.
|