vendor/agent/ is a package like any other - agent.flan declares three calls, flan_agent.c implements them, link asks for -lpthread. start listens on a unix socket, poll installs whatever arrived and says how many, wait does the same after waiting for something. The split between poll and the listener is the whole design. dlopen relocates a module and takes the loader lock, which is milliseconds and unbounded, so it happens on the listener thread. flan_reload_install is one store per function and must not land while a redefined function is on the stack, so it happens on the game thread at the top of the frame, when the program asks. A ring and two atomics connect them; the game thread never blocks on the loader. wait exists for tests. A test that races the frame rate fails on a loaded machine, so test/programs/agent.flan waits for the reload rather than sleeping past it. It also sends a junk path first: the daemon is a separate process and can send anything, and a bad path must be refused rather than take down the program it was sent to. Two things came out of running it. The reply goes out before the module is queued, because the other way round the game thread can install and the program can exit between the two, and the answer reaches the sender as a connection reset instead of as ok. And ok means queued, not installed - the sender does not get to know when the swap happened, since only the program knows when it is between frames. sand.flan now polls at the top of its loop, which is what this step was for. Under Xvfb, one line on the socket and 455 consecutive frames drew from a game-draw that did not exist when the process started. Building without --dev still works: there are no cells, so a module is refused on the listener thread and the loop never notices. flan reload builds one module the way the daemon will. --new names what the host was not built with, which is the one thing the command cannot work out for itself and exactly what the session will track.
31 lines
1.0 KiB
Plaintext
31 lines
1.0 KiB
Plaintext
;;;; The agent, end to end: a running program takes a redefinition over a
|
|
;;;; socket and installs it between "frames".
|
|
;;;;
|
|
;;;; [tick] is the function that gets redefined. It is called once before the
|
|
;;;; reload and once after, and nothing else in this file changes, so the two
|
|
;;;; numbers are the whole result.
|
|
;;;;
|
|
;;;; It waits rather than polling on a timer because a test that races the
|
|
;;;; frame rate is a test that fails on a loaded machine. A game loop calls
|
|
;;;; poll at the top of the frame and ignores the answer; the split is in
|
|
;;;; vendor/agent/agent.flan.
|
|
(import agent "vendor:agent")
|
|
|
|
(defvar ticks i64)
|
|
|
|
(defn tick [] i64
|
|
(set ticks (+ ticks 1))
|
|
ticks)
|
|
|
|
(defn main [args [string]] i32
|
|
(if (< (len args) 2)
|
|
(do (print-line "usage: agent <socket>") 2)
|
|
(do
|
|
(if (< (agent/start (at args 1)) 0)
|
|
(do (print-line "cannot listen") 1)
|
|
(do
|
|
(print-i64 (tick)) (newline)
|
|
(while (= (agent/wait 100) 0) 0)
|
|
(print-i64 (tick)) (newline)
|
|
0)))))
|