| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Requests to an app that checks tokens go 2.92% slower than to an open
one on 64 keep-alive connections, 2.2% of it the head the token makes
longer (an open app sent the same head is as slow); hashing every
request on a new connection costs 0.91%. 031 measures the three in
turns.
|
| |
|
|
|
|
|
|
|
| |
An app given a tokens file (tokens=FILE, --tokens FILE) takes requests
bearing a token whose SHA-256 the file lists: read for its views, queries
and documents, write for all, input=NAME for one input alone; 401
without one, 403 past its grant. A delivery another node sealed needs
none: its key told who sent it. A connection keeps its last token's
grant; a reading swaps the tokens without stopping the app.
|
| |
|
|
|
|
|
|
|
| |
The use after free in local_done and the owner's lock made after another
app's outlet used it were found reading the code, not by the check,
which passed with both before it was made to change senders (115, 017).
The usage now says changed lines change in place unless their store
moved; and 115 names the path no check takes: a module refused while
changing in place.
|
| |
|
|
|
|
|
|
|
|
| |
Changing an app in place keeps a million items' app answering but for
1.12 ms (a host restart: 150 ms; stopping and starting it again from its
store, as first built, 150.4 ms), 171.5 ms when its records change shape
(332 ms). Another app's p99 stays 0.97 times as it was while one changes
every 0.2 s; a host of one app is as it was (TPC-C +0.7%, instructions
at most +0.02%); each module change leaves 19 KB. 030 holds the windows
of both builds, the isolation, the pairs, the counts and the memory.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(017, stage 3)
The --apps file is the host's shape: on SIGHUP the host reads it again
and starts the apps of new lines, stops those of lines gone, starts
again those whose line changed (states carried by name from the store)
and those stopped or uncertain. A request carries the module it was
resolved with, and is not applied under another (503 stopped); link
streams and local outlets look their input up again. Route
authentication (3b) is designed apart.
|
| |
|
|
|
|
|
| |
The loop alone slowed four links to half: woken by every record queued,
it chased the owner a record at a time. Pushing once a turn made links
1.6 times as fast, with threads or the loop alike; the loop's own cost
is within the noise. Twenty outputs now add two threads, not 21.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each link and each HTTP wire sends on a thread of its own: a host with
twenty outputs runs twenty-one threads more than one without. 2b moves
them into one sending loop: an epoll over the links' UDP sockets and
the wires' TCP sockets with one wake, waiting until the soonest link
timer or wire pause. Links (2b-1) do in the loop what their threads
did each round; wires (2b-2) become a non-blocking HTTP/1.1 client
state machine, with non-blocking steps added to the crypto table for
TLS. A name looked up again still waits where it is, and says so.
Before building: every link, wire, answer and seal check green; a host
of ten links and ten wires two threads above one without; and link and
wire throughput, alternated before and after, no more than 5% lower at
the median (four links together: 10%).
|
| |
|
|
|
|
|
|
| |
Stage 2 is built and measured: what was learned (the receiving side
needed nothing new, an output goes one way only) and the numbers. The
checkpoint adds sending to the many-apps row, and keeps 2b (one loop
for the send threads) and stage 3 (apps added and replaced while the
host runs) among what is left.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
show (017)
Stage 2: each app of --apps takes its wiring (send=, seal=, reply=), its
sends' source being APP.OUTPUT; one --link-port takes every app's
inputs, a stream's input name APP/INPUT (012 unchanged); and send=
OUTPUT=APP/INPUT hands an app's saved sends to another app of the same
host with no socket, seal or packet: an outlet with the window links
have, a batch of records as a link delivers them put in the receiving
app's queue, applied after its last number heard, and the number heard
after its save trimming the sender's outbox. Merging the send threads
into one loop is split off as 2b.
Before building: it goes in if the inner outlet stores at least as many
sends a second as a loopback pure:// link between the same two apps,
at half the host's CPU a stored send or less; checked by a host sending
to an app of its own and to one of another host, exactly once and in
order across a kill -9, and held back by a full receiver.
|
| |
|
|
|
|
|
|
|
|
| |
017's first stage is built and measured: the shape now says what was
built where it differs from the design (work counted as written,
nothing counted without a budget, every app of --apps run by workers,
a busy app kept on its worker, a home thread for each app's
connections), and what was learned on the way. The checkpoint lists
many apps on one host among what Pure shows, and stages 2 and 3 among
what is left.
|
|
|
pure-serve runs one app a process: a module, a store, its own threads,
port and key, scheduled by Linux. Within one process nothing bounds an
event's run (it grows with its lists), the requests waiting for the
owner, or one store's sync, which holds every other store's commit
since the tree store has one writer's turn per process.
017 makes an app an execution domain (007): a host of many apps
(--apps FILE, routes /APP/...) runs them by turns on a fixed number of
worker threads, none per app; budgets per app in deterministic units
(memory in stored bytes as before, work in instructions counted per
block and per item visited, queue in requests: 422 work, 503 busy);
writer turns per store; and an app that cannot start or whose save
became uncertain stops alone. Stage 1 is all that; links, sends between
apps and an app's lifetime come after.
Before building: it goes in if an app B's p99 under app A's flood is
within 1.5 times what two processes give, an app costs under a quarter
of an idle process's own memory with no thread of its own, the pair's
throughput is within 10% of two processes', and a one-app host keeps
its speed (3% in time, 1% in instructions).
|
