Joseph Ferano
e22a8dba82
The 4K result cap and condition_name[128] are on the agent's socket path, which is why the sanitizer corpus cannot reach them: a program in the sweep has no socket and nobody on the other end of it. test_agent has both. A 5000-byte string literal evaluated into the running program comes back as exactly 4096 bytes ending in the ellipsis result_end puts there to say it clamped — and it comes back through the seqlock's copy, so the cap and the new reader are pinned by the same case. The header also shows the generation as 1, which is the count of complete values rather than the raw counter. A condition class of 198 characters comes back from `status` as 127 and a terminator. Aborting out of that break is what pins the exit status at 134 now that the loop leaves with _exit rather than exit. SNAP_MAX, SNAP_NAMES and the dev registry's overflow guard are still read rather than tested. Sixty-five nested restart-cases and four thousand interned names are a lot of program to write for a clamp each, and neither is on a path this session changed. flan_dev_result_cap() exists so the size is asked for rather than written down in two files: "the copy is never truncated" is only true while the agent's buffer and the runtime's bound agree, and the agent checks that where the copy happens. The pipe the queue program blocks on is close-on-exec, or the child inherits the write end and its own stdin never reaches end of file — it sat in its last read waiting for a byte only it could send.
44 lines
1.8 KiB
Plaintext
44 lines
1.8 KiB
Plaintext
;;;; The job ring between the listener thread and the game thread, and what it
|
|
;;;; does when it is full.
|
|
;;;;
|
|
;;;; The window this needs is "the listener has queued modules the game thread
|
|
;;;; has not looked at yet", and that window has to be held open by something
|
|
;;;; other than a timer — how long sixty-five connections take on a loaded
|
|
;;;; machine is exactly the kind of race a test must not be. So the program
|
|
;;;; blocks on stdin: the test fills the ring, checks what the agent said, and
|
|
;;;; only then writes the byte that lets the program poll.
|
|
(import agent "vendor:agent")
|
|
|
|
;;; libc's, declared straight: no aggregate crosses the boundary, so there is
|
|
;;; nothing for a shim to do.
|
|
(declare stdin-byte [] i32 "getchar")
|
|
|
|
(defvar ticks i64)
|
|
|
|
(defn tick [] i64
|
|
(set ticks (+ ticks 1))
|
|
ticks)
|
|
|
|
(defn main [args [string]] i32
|
|
(if (< (len args) 2)
|
|
(do (println "usage: agent-queue <socket>") 2)
|
|
(do
|
|
(if (< (agent/start (at args 1)) 0)
|
|
(do (println "cannot listen") 1)
|
|
(do
|
|
(println "ready")
|
|
(stdin-byte)
|
|
;; How many the ring actually held. Every module queued is installed
|
|
;; here, so this number is the count of slots that survived — which
|
|
;; is the whole claim: a ring that overwrote the slot it was reading
|
|
;; would answer with something else.
|
|
(print (agent/poll)) (println "")
|
|
;; Round two: one evaluated expression, whose rendering is longer
|
|
;; than the 4K the dev runtime will hold. The program has to still be
|
|
;; here afterwards for the value to be read back off the socket, so
|
|
;; it waits a third time and leaves on end of file.
|
|
(stdin-byte)
|
|
(print (agent/poll)) (println "")
|
|
(stdin-byte)
|
|
0)))))
|