StackExchange/dnscontrol
1
1
Fork 0
mirror of https://github.com/StackExchange/dnscontrol.git synced 2025-11-17 22:41:58 +08:00
Code Issues Projects Releases Packages Wiki Activity

DOCS: expand upon concurrency (#3676)

Browse source
This commit is contained in:
Phil Pennock 2025-07-22 10:01:10 -04:00 • committed by GitHub
parent af5907aafd
commit ecbc4992d0
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 29 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
.editorconfig
View file

@ -26,6 +26,11 @@ indent_size = 2
indent_style = space
trim_trailing_whitespace = true
# Markdown
# Whitespace at EOL can be significant, so is not safe to strip.
[*.md]
trim_trailing_whitespace = false
# GNU make
# https://www.gnu.org/software/make/manual/html_node/Recipe-Syntax.html
[Makefile]

24
documentation/advanced-features/concurrency-verified.md
View file

@ -2,15 +2,35 @@
name: CONCURRENCY_VERIFIED
---
✅ - A checkmark means "this has been tested, and will run concurrently".
❔ - The questionmark means "it hasn't been tested, safety unknown"
✅ - A checkmark means "this has been tested, and will run concurrently".
❔ - The questionmark means "it hasn't been tested, safety unknown"
❌ - The red "X" means "this has been tested, and it will _not_ work concurrently".
Concurrency in this context is about gathering zone data, as seen during the
preview stage when fetching current data for all zones.
### Here's how to perform a test:
1. Build dnscontrol with the -race flag: go build -race (this makes a special binary)
2. Run this special binary: `dnscontrol preview` with a configuration that lists at least 4 domains using the provider in question. More domains is better.
3. The special binary runs much slower (1/10th the speed) because it is doing a lot of checking.
If it reports problems, the error message will indicate where the problem is.
It might not be 100% accurate, but it will be in the right area.
### Development guidance
Loosely, each Provider has a top-level struct named `{providername}Provider`;
if this state is just some simple data-types initialized once before
processing starts, and then only read, then the provider is likely to be
concurrency-safe.
If this contains state which is updated (eg, caches) then the provider is
probably not concurrency-safe unless every routine accessing it is protected
by appropriate primitives.
Eg, URLs and auth credentials are fine.
An account ID determined on the first query?
That probably needs to be protected, even if every fetch returns the same data.
The `-race` build is a helpful hint but is not a guarantee.

4
providers/capabilities.go
View file

@ -19,8 +19,8 @@ const (
// so folks can ask for that.
CanAutoDNSSEC Capability = iota
// CanConcur indicates the provider can be used concurrently. Can()
// indicates that it has been tested and shown to work concurrently.
// CanConcur indicates the provider can be used concurrently to gather zone data.
// Can() indicates that it has been tested and shown to work concurrently.
// Cannot() indicates it has not been tested OR it has been shown to not
// work when used concurrently. The default is Cannot().
CanConcur