Joseph Ferano
23a1b6c6fb
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.
22 lines
1.0 KiB
Plaintext
22 lines
1.0 KiB
Plaintext
;;;; The dev agent, as Flan sees it. Three calls, and the shape of them is the
|
|
;;;; design: loading a redefinition and installing it are separate, because
|
|
;;;; only the program knows when it is between frames.
|
|
;;;;
|
|
;;;; (agent/start path) listen on a unix socket; once, at startup
|
|
;;;; (agent/poll) install whatever has arrived; returns how many
|
|
;;;; (agent/wait ms) the same, but waits for something first
|
|
;;;;
|
|
;;;; A game loop calls poll at the top of the frame and ignores the result.
|
|
;;;; wait is for a headless test, where waiting is what makes a reload
|
|
;;;; deterministic rather than a race against the frame rate.
|
|
;;;;
|
|
;;;; No aggregate crosses this boundary, so there is no shim: a Flan string is
|
|
;;;; already ptr+len and flan_agent_start takes it that way.
|
|
(declare start-raw [path string] i32 "flan_agent_start")
|
|
(declare poll-raw [] i32 "flan_agent_poll")
|
|
(declare wait-raw [ms i32] i32 "flan_agent_wait")
|
|
|
|
(defn start [path string] i32 (start-raw path))
|
|
(defn poll [] i32 (poll-raw))
|
|
(defn wait [ms i32] i32 (wait-raw ms))
|