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
Lignes+2121 -1252
Lecture3 min
22 sur 22 entrées · 29 commits upstream
#
Entrée
Catégorie
Unités
1
Critique
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
Correctifsauto
mormot.net.client+1
b1b1f67d+744-385
2
Moyenne
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
Correctifsauto
mormot.net.client
d492c4b0+102-7
Unités
3
Moyenne
net: fixed async server potential thread race
Correctifsauto
mormot.net.async
a333a689+24-11
Unités
4
Moyenne
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.
Correctifsauto
mormot.net.async
4b07c730+17-3
Unités
5
Moyenne
boot: fixed bootstrap script
Correctifsauto
2194da9b+9-9
6
Moyenne
net: fixed Windows compilation ;)
Correctifsauto
mormot.net.async
56e2752a+3-3
Unités
7
Moyenne
boot: new boot/ sub-folder to bootstrap a FPC build env for AI agents
Nouveautésauto
16e06575+647-3
8
Moyenne
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
Nouveautésauto
mormot.core.fpcx64mm
c5d4f5c3+55-17
Unités
9
Moyenne
core: add opt-in full small-block sharding
Nouveautésauto
mormot.core.fpcx64mm
58abf7f0+44-5
Unités
10
Faible
core: read Win64 thread ID directly from the TEB
Compilateur & plateformeauto
mormot.core.fpcx64mm
a7f1068b+4-6
Unités
11
Faible
boot: updated script for better FPC configuration file
Compilateur & plateformeauto
8b33b6b1+5-4
12
Faible
core: #563 code cleanup
- no functional change
Sous le capotauto
mormot.core.fpcx64mm
73e34c56+29-28
Unités
13
Faible
core: minor code refactoring
- no functional change
Sous le capotauto
mormot.core.fpcx64mm+1
09bdf54c+7-8
14
Faible
tests: let TNetworkProtocols.Tunnel cover relay.AgentInfo method
Testsauto
46cc440e+75-2
15
Faible
test: ensure expected exception are not logged
- after #566
- includes also minor comment precisions
Testsauto
mormot.core.fpcx64mm+1
6340aef4+26-20
16
Faible
boot: removed this boot/ experiment which was disastrous
- ChatGpt was not aware of its own limitations - what a waste of time!
Entretienauto
aa59acd2+3-647
17
Faible
core: always prefetch a MM medium block outside of the lock
- does not seem to reduce the contention, but should help anyway
Entretienauto
mormot.core.fpcx64mm
14caddba+47-15
Unités
18
Faible
core: MM allow eventual OS reclaim after #563
Entretienauto
mormot.core.fpcx64mm
8343fa49+28-25
Unités
19
Faible
core: refined TMediumBlockInfo CPU cache alignment
- each lock should be on its own cache line
Entretienauto
mormot.core.fpcx64mm+1
094f81d5+19-15
20
Faible
core: retain repeatedly reused small-block pools
Entretienauto
mormot.core.fpcx64mm
6768230c+20-1
Unités
21
Faible
core: skip medium-to-large fallback with per-thread arenas
Entretienauto
mormot.core.fpcx64mm
4ca2fd27+8-4
Unités
22
Faible
core: reset small pool reuse on cold release path
Entretienauto
mormot.core.fpcx64mm
103c03a8+5-4
Unités
Commits977
Jours actifs44/60
Plus chargé2026-09-30
Pic60
2026-08-152026-10-13