On Windows, tinysleep used Sleep(0), which only yields the remainder of the current time slice and leaves the waiter runnable. Current impact is that object_state_deactivate() and refcount deletion waits can spin at high CPU while waiting for holder threads; potential impact is the same scheduler starvation in any tinysleep wait loop.

Use Sleep(1) for Windows tinysleep so waiters become non-runnable briefly, matching the helper's sleep semantics and the POSIX nanosleep branch. Leave yield_the_processor() as Sleep(0) for code that explicitly wants a yield.

Functional impact: Windows tinysleep callers now wait for a real short sleep instead of a zero-duration yield; no API, config, metric, protocol, or command surface changes. POSIX behavior is unchanged.

Performance impact: Windows wait/backoff loops can add about 1 ms per retry, bounded by the process timer resolution, while avoiding CPU-bound spins that delay holder or releaser work.

Security impact: reduces denial-of-service risk from a high-CPU wait loop and introduces no new input, memory ownership, credentials, or privilege boundary.

Validation: git diff --check; source search for Sleep(0), Sleep(1), SwitchToThread, and tinysleep; required independent source review approved the change.
(cherry picked from commit b675c10)

WEBRTC_DC.open is documented and read as an atomic flag. The close callback already stores false with __atomic_store_n(), and all active readers go through webrtc_dc_is_open(), but myOpenCallback() stored true with a plain assignment.

This is a current bug in HAVE_LIBDATACHANNEL builds: libdatachannel callbacks and web request handling can observe WEBRTC_DC.open concurrently, so mixing one plain writer with atomic readers/writers creates a C memory-model data race.

Store the open=true transition with __atomic_store_n(..., __ATOMIC_RELAXED), matching the existing close=false store and the relaxed load helper. The callback still writes the same value at the same point after the same checks and logging.

Functional impact: no intended behavior change. The data-channel open contract, callback registration, return contract, request handling, and cleanup flow are unchanged; only the storage primitive becomes consistent with the field contract.

Performance impact: negligible. This adds one relaxed atomic store on a data-channel lifecycle callback, not on a hot request loop.

(cherry picked from commit a894baa)

The MQTT client kept PINGREQ send-progress state in a file-scope ping_frag while mqtt_ng_init() can create independent mqtt_ng_client instances. That made fragment fields such as sent and sent_monotonic_ut shared by every client, even though the state is logically per connection.

This is a potential data race and state-aliasing bug. Current production appears to use a single ACLK MQTT client, but the library boundary and tests allow multiple client instances, so the global mutable fragment was the wrong lifetime for the data it stored.

Move the mutable ping fragment into struct mqtt_ng_client and initialize it with the same PINGREQ bytes and flags for each client. Add a transaction-buffer stable_frag pointer so buffer compaction and growth still preserve the external ping fragment while invalidating ordinary header-buffer fragments as before.

Functional impact: single-client protocol behavior is unchanged. PINGREQ ordering, sent accounting, queued-message accounting, and PINGRESP latency accounting keep the same semantics; they now use the owning client state instead of process-global mutable state.

Performance impact: negligible. The change adds one buffer_fragment in each client and one pointer in the private transaction buffer, with no new allocation, lock, atomic operation, loop, or network-path work.

(cherry picked from commit e154e1c)