Erik JohnstonandClaude Fable 5
c3dfbfc6ef
The "current logcontext" slot moves from a Python threading.local into the Rust extension, together with a native port of LoggingContext. A Python thread-local is invisible to Rust: each tokio worker thread would see its own slot, permanently at the sentinel, so logging emitted from Rust could not be attributed to the request that caused it. This lays the storage groundwork; a follow-up change gives tokio tasks a task-scoped capture (see the module-doc TODO). Design notes, for review: - The slot is typed: Option<Py<LoggingContext>>, with None representing the sentinel. The _Sentinel class and SENTINEL_CONTEXT singleton stay pure Python, unchanged; thin wrappers on current_context and set_current_context in synapse.logging.context convert between the singleton and None at the boundary, so no Rust code ever sees or produces the sentinel object. pyo3's extraction enforces the type: anything that is not a LoggingContext (or subclass) or None raises TypeError. - The accounting policy is native too: set_current_context reads the thread rusage once via libc (no per-switch struct_rusage allocation) and runs the stop/start bookkeeping inline for base LoggingContexts, only dispatching through Python for subclasses (BackgroundProcessLoggingContext) so their overrides run. start()/stop() now take an Optional[tuple[float, float]] instead of a struct_rusage, the get_thread_resource_usage/is_thread_resource_usage_supported/ get_thread_id module helpers are gone, LoggingContext.previous_context is now Optional[LoggingContext] (None where it used to hold SENTINEL_CONTEXT), and the nominally-private _resource_usage attribute is no longer exposed (nothing read it; use get_resource_usage()) — worth an upgrade note when this is released, as out-of-tree code may rely on the old shapes. - The switch path avoids per-operation allocation and Python round-trips: names are stored as Py<PyString> (LoggingContextFilter reads server_name and str(context) per log record process-wide, now INCREF-only), error messages materialise the context name only in the cold branches, and the thread id is read via PyThread_get_thread_ident (the exact value threading.get_ident() returns) rather than by calling into Python. - The attribute surface, method set and error-message wording are a compatibility contract, pinned by the characterization tests (which now exercise the tuple-based start/stop API). - The opt-in synapse.logging.context.debug switch traces are emitted from Rust via pyo3-log, whose level cache only refreshes on reset_logging_config(); docs/log_contexts.md documents the manhole procedure. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFbRtswu7rsHrttJFauUUb
Synapse Documentation
The documentation is currently hosted here. Please update any links to point to the new website instead.
About
This directory currently holds a series of markdown files documenting how to install, use and develop Synapse. The documentation is readable directly from this repository, but it is recommended to instead browse through the website for easier discoverability.
Adding to the documentation
Most of the documentation currently exists as top-level files, as when organising them into
a structured website, these files were kept in place so that existing links would not break.
The rest of the documentation is stored in folders, such as setup, usage, and development
etc. All new documentation files should be placed in structured folders. For example:
To create a new user-facing documentation page about a new Single Sign-On protocol named "MyCoolProtocol", one should create a new file with a relevant name, such as "my_cool_protocol.md". This file might fit into the documentation structure at:
- Usage
- Configuration
- User Authentication
- Single Sign-On
- My Cool Protocol
- Single Sign-On
- User Authentication
- Configuration
Given that, one would place the new file under
usage/configuration/user_authentication/single_sign_on/my_cool_protocol.md.
Note that the structure of the documentation (and thus the left sidebar on the website) is determined by the list in SUMMARY.md. The final thing to do when adding a new page is to add a new line linking to the new documentation file:
- [My Cool Protocol](usage/configuration/user_authentication/single_sign_on/my_cool_protocol.md)
Building the documentation
The documentation is built with mdbook, and the outline of the documentation is determined by the structure of SUMMARY.md.
First, get mdbook. Then, from the root of the repository, build the documentation with:
mdbook build
The rendered contents will be outputted to a new book/ directory at the root of the repository. Please note that
index.html is not built by default, it is created by copying over the file welcome_and_overview.html to index.html
during deployment. Thus, when running mdbook serve locally the book will initially show a 404 in place of the index
due to the above. Do not be alarmed!
You can also have mdbook host the docs on a local webserver with hot-reload functionality via:
mdbook serve
The URL at which the docs can be viewed at will be logged.
Synapse configuration documentation
The Configuration Manual page is generated from a YAML file, schema/synapse-config.schema.yaml. To add new options or modify existing ones, first edit that file, then run scripts-dev/gen_config_documentation.py to generate an updated Configuration Manual markdown file.
Build the book as described above to preview it in a web browser.
Configuration and theming
The look and behaviour of the website is configured by the book.toml file at the root of the repository. See mdbook's documentation on configuration for available options.
The site can be themed and additionally extended with extra UI and features. See website_files/README.md for details.