pure/prototypes/connections/server.c, branch masterVerified execution runtime unifying state, persistence, and replication.
http://git.yeowoo.org/pure/atom?h=master2026-10-01T15:40:11ZLook at a wake write's result in the prototype, as fortified builds ask2026-10-01T15:40:11Zeunhhunecpition205@gmail.com2026-10-01T15:40:11Zurn:sha1:1fdf72444cdcf5041022c75ed616a1dcd458175b
Ubuntu's gcc defines _FORTIFY_SOURCE, which marks write's result as one
to use, and a (void) cast does not quiet it: the prototype did not
build there (research 029). Debian's does not define it; the Pi gives
the same error with -D_FORTIFY_SOURCE=3.
Serve modules over persistent connections2026-09-26T04:40:20Zeunhhunecpition205@gmail.com2026-09-26T04:40:20Zurn:sha1:7771461a93f993425f97d4e05c91e64d17179e60
pure-serve replaces the module mode of server.c, which goes back to what
it was. It keeps the document contract, the runtime core (a work slot per
connection, the payload budget, core-owned ingress, borrowed PUT replies)
and the group commits, and adds what server.c lacked: HTTP/1.1 persistent
connections with in-order pipelining, an edge-triggered epoll owner
thread, up to 1,024 connections allocated as they arrive and reused, one
writev per answer, and documents opened through a store handle.
On the Pi 5 with one thread it serves 106k small keep-alive reads per
second (axum on three cores: 126k) at the same p99, 1,741 1 MiB reads
(axum: 1,370), and 1,126 durable writes from 64 connections (crash-safe
axum: 372), in 7.3 MiB against axum's 17-20 MiB. Note 075 has the table.
Serve modules through the runtime core with group commits2026-09-26T03:53:55Zeunhhunecpition205@gmail.com2026-09-26T03:53:55Zurn:sha1:3b89ae82ea9468d54c60a63fd03b9a829748a0ac
pure-connections-module offers the document server's HTTP contract with an
aup module: GET is its show message and PUT its edit message. Requests go
through the runtime core as before (work slots, payload budget, ingress,
replies borrowed from the request), and effects are taken on the owner
thread with the core's asynchronous interface.
Each poll round is one burst: every ready request is applied to the app
with deferred saving, one save stores them, and only then are the tickets
completed and answered. A failed save fails the whole burst, reads too. A
key seen again ends the burst first, and the module server accepts every
waiting connection at once so concurrent requests share a burst. On the
Pi's SD card eight clients' 240 edits take 0.59 s instead of 2.14 s.
Establish native micro runtime checkpoint2026-09-24T16:14:54Zeunhhunecpition205@gmail.com2026-09-24T16:14:54Zurn:sha1:b1ce1927022d374198441afafeb27199fc8a052a