Thursday 03 September 2026

29 commits landed upstream

This edition has not been reviewed yet: the entries below are classified automatically from commit messages and diffs, without an editorial pass. Treat the categories as hints and follow the commit links for the truth.

Build2.4.16672 → 2.4.16701

Commits29

Lines+2121 -1252

Read3 min

22 of 22 entries · 29 commits upstream

# Entry Category Units

1 Critical net: rewritten mormot.net.tunnel.pas - the core now is cleaner via a new ITunnelOpenState interface as main engine - fixed a lot of race conditions and other issues Fixesauto mormot.net.client+1 b1b1f67d+744-385

Units

mormot.net.client mormot.net.tunnel

Arnaud Bouchez · 18:12 UTC · view the commit on GitHub →

2 Medium net: fixed THttpMultiPartStream duplicated closing boundaries - fix #565 THttpMultiPartStream.Flush appended the closing --boundary-- lines on every call, and THttpClientSocket.RequestInternal computed Content-Length: from InStream.Size before its Seek(0, soBeginning) triggered another Flush: the body sent was 22 bytes longer than announced, and the server parsed the trailing boundary as the next request line (http.sys: 400 Invalid Verb). Every retry - e.g. each round trip of the NTLM/Negotiate handshake - added one more copy. - Flush now appends the closing boundaries only once (fFlushed flag), so it is safe to call it any number of times - Add*() after Flush raise EHttpSocket instead of producing a broken body (AddFile checks before opening the file) - RequestInternal rewinds InStream before Content-Length: is computed, so Size is right even without an explicit Flush call - tests: Flush/Seek idempotency and byte-exact re-read in TTestCoreBase.MultiPartDecoder; two keep-alive POST of the same stream (plus a never-flushed one) against THttpServer and THttpAsyncServer in TNetworkProtocols.DoHttpBodyDownload - both red before the fix Fixesauto mormot.net.client d492c4b0+102-7

Units

mormot.net.client

Sven Harazim · 13:55 UTC · PR #565 · view the commit on GitHub →

3 Medium net: fixed async server potential thread race Fixesauto mormot.net.async a333a689+24-11

Units

mormot.net.async

Arnaud Bouchez · 09:15 UTC · view the commit on GitHub →

4 Medium net: fix lost thread wakeup in TAsyncConnections.ThreadPollingWakeupOne/Events Since 73cb95431 the R1..Rn atpReadPending threads are woken up through two CAS counters (fWakeupOne/fWakeupEvents) consumed by ThreadPollingWakeupLocked, which is entered only after a successful fWakeupSafe.TryLock. If a caller increments a counter just after the current lock holder did its LockedGet32() and then fails its own TryLock, nobody consumes that request: fWakeupOne stays at 1, so every further ThreadPollingWakeupOne() fails its "if not already notified" CAS and returns without doing anything. On an idle server this is fatal: the R0 atpReadPoll thread sleeps in WaitForEver (no subscribed connection) or polls epoll forever (accepted connections are not subscribed before their first read), accept() keeps succeeding but the new connections are never processed - the process is alive but the HTTP server is dead, with CLOSE-WAIT sockets piling up. Observed on production RK3588 boards (THttpAsyncServer, 8 threads) after 8-18 hours, and reproduced in about 4 minutes (114 rounds) with a mix of concurrent short-lived and keep-alive connections separated by idle gaps: /proc stacks showed R0 in TSynEvent.WaitFor(INFINITE) from DoExecute and R1 idle in WaitForEver, with no runnable thread. Fix: - ThreadPollingWakeupLocked: after UnLock, re-check both counters and run once more if any is non-zero and the lock can be re-acquired, so a request raced against the holder is never left pending. - ThreadPollingWakeupOne: always attempt the TryLock, even when fWakeupOne was already set, so a pending notification is self-healing on the next accept() instead of silently disabling all further wakeups. With this change the same stress ran 1910 rounds / 45 minutes without any stall (and 1160 rounds in a first 28 minutes run), where the previous code died at round 114. Fixesauto mormot.net.async 4b07c730+17-3

Units

mormot.net.async

zen010101 · 02:21 UTC · view the commit on GitHub →

5 Medium boot: fixed bootstrap script Fixesauto 2194da9b+9-9

Arnaud Bouchez · 12:15 UTC · view the commit on GitHub →

6 Medium net: fixed Windows compilation ;) Fixesauto mormot.net.async 56e2752a+3-3

Units

mormot.net.async

Arnaud Bouchez · 13:45 UTC · view the commit on GitHub →

7 Medium boot: new boot/ sub-folder to bootstrap a FPC build env for AI agents New featuresauto 16e06575+647-3

Arnaud Bouchez · 12:13 UTC · view the commit on GitHub →

8 Medium core: new FPCMM_MEDIUMTOLARGE conditional - enabled on FPCMM_SERVER - will fallback to the large allocator on medium contention of blocks > 48KB - seems like a simple but very efficient fallback strategy New featuresauto mormot.core.fpcx64mm c5d4f5c3+55-17

Units

mormot.core.fpcx64mm

Arnaud Bouchez · 13:44 UTC · view the commit on GitHub →

9 Medium core: add opt-in full small-block sharding New featuresauto mormot.core.fpcx64mm 58abf7f0+44-5

Units

mormot.core.fpcx64mm

Mike · 17:38 UTC · view the commit on GitHub →

10 Low core: read Win64 thread ID directly from the TEB Compiler & platformauto mormot.core.fpcx64mm a7f1068b+4-6

Units

mormot.core.fpcx64mm

Mike · 23:27 UTC · view the commit on GitHub →

11 Low boot: updated script for better FPC configuration file Compiler & platformauto 8b33b6b1+5-4

Arnaud Bouchez · 12:24 UTC · view the commit on GitHub →

12 Low core: #563 code cleanup - no functional change Under the hoodauto mormot.core.fpcx64mm 73e34c56+29-28

Units

mormot.core.fpcx64mm

Arnaud Bouchez · 08:41 UTC · PR #563 · view the commit on GitHub →

13 Low core: minor code refactoring - no functional change Under the hoodauto mormot.core.fpcx64mm+1 09bdf54c+7-8

Units

mormot.core.fpcx64mm mormot.net.tunnel

Arnaud Bouchez · 18:45 UTC · view the commit on GitHub →

14 Low tests: let TNetworkProtocols.Tunnel cover relay.AgentInfo method Testsauto 46cc440e+75-2

Arnaud Bouchez · 18:14 UTC · view the commit on GitHub →

15 Low test: ensure expected exception are not logged - after #566 - includes also minor comment precisions Testsauto mormot.core.fpcx64mm+1 6340aef4+26-20

Units

mormot.core.fpcx64mm mormot.net.client

Arnaud Bouchez · 15:32 UTC · view the commit on GitHub →

16 Low boot: removed this boot/ experiment which was disastrous - ChatGpt was not aware of its own limitations - what a waste of time! Housekeepingauto aa59acd2+3-647

Arnaud Bouchez · 14:07 UTC · view the commit on GitHub →

17 Low core: always prefetch a MM medium block outside of the lock - does not seem to reduce the contention, but should help anyway Housekeepingauto mormot.core.fpcx64mm 14caddba+47-15

Units

mormot.core.fpcx64mm

Arnaud Bouchez · 12:16 UTC · view the commit on GitHub →

18 Low core: MM allow eventual OS reclaim after #563 Housekeepingauto mormot.core.fpcx64mm 8343fa49+28-25

Units

mormot.core.fpcx64mm

Arnaud Bouchez · 08:15 UTC · PR #563 · view the commit on GitHub →

19 Low core: refined TMediumBlockInfo CPU cache alignment - each lock should be on its own cache line Housekeepingauto mormot.core.fpcx64mm+1 094f81d5+19-15