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.
版本号2.4.16672 → 2.4.16701
提交29
行数+2121 -1252
阅读3 分钟
22 条中的 22 条 · 上游 29 次提交
#
条目
类别
单元
1
严重
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
修复auto
mormot.net.client+1
b1b1f67d+744-385
2
中
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
修复auto
mormot.net.client
d492c4b0+102-7
3
中
net: fixed async server potential thread race
修复auto
mormot.net.async
a333a689+24-11
4
中
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.
修复auto
mormot.net.async
4b07c730+17-3
5
中
boot: fixed bootstrap script
修复auto
2194da9b+9-9
6
中
net: fixed Windows compilation ;)
修复auto
mormot.net.async
56e2752a+3-3
7
中
boot: new boot/ sub-folder to bootstrap a FPC build env for AI agents
新功能auto
16e06575+647-3
8
中
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
新功能auto
mormot.core.fpcx64mm
c5d4f5c3+55-17
9
中
core: add opt-in full small-block sharding
新功能auto
mormot.core.fpcx64mm
58abf7f0+44-5
10
低
core: read Win64 thread ID directly from the TEB
编译器与平台auto
mormot.core.fpcx64mm
a7f1068b+4-6
11
低
boot: updated script for better FPC configuration file
编译器与平台auto
8b33b6b1+5-4
12
低
core: #563 code cleanup
- no functional change
内部重构auto
mormot.core.fpcx64mm
73e34c56+29-28
13
低
core: minor code refactoring
- no functional change
内部重构auto
mormot.core.fpcx64mm+1
09bdf54c+7-8
14
低
tests: let TNetworkProtocols.Tunnel cover relay.AgentInfo method
测试auto
46cc440e+75-2
15
低
test: ensure expected exception are not logged
- after #566
- includes also minor comment precisions
测试auto
mormot.core.fpcx64mm+1
6340aef4+26-20
16
低
boot: removed this boot/ experiment which was disastrous
- ChatGpt was not aware of its own limitations - what a waste of time!
杂项auto
aa59acd2+3-647
17
低
core: always prefetch a MM medium block outside of the lock
- does not seem to reduce the contention, but should help anyway
杂项auto
mormot.core.fpcx64mm
14caddba+47-15
18
低
core: MM allow eventual OS reclaim after #563
杂项auto
mormot.core.fpcx64mm
8343fa49+28-25
19
低
core: refined TMediumBlockInfo CPU cache alignment
- each lock should be on its own cache line
杂项auto
mormot.core.fpcx64mm+1
094f81d5+19-15
20
低
core: retain repeatedly reused small-block pools
杂项auto
mormot.core.fpcx64mm
6768230c+20-1
21
低
core: skip medium-to-large fallback with per-thread arenas
杂项auto
mormot.core.fpcx64mm
4ca2fd27+8-4
22
低
core: reset small pool reuse on cold release path
杂项auto
mormot.core.fpcx64mm
103c03a8+5-4
提交977
活跃天数44/60
最忙一天2026-09-30
峰值60
2026-08-152026-10-13