mirror of
https://github.com/bherbruck/solidcraft.git
synced 2026-11-08 04:52:10 +00:00
Mateusz Sych
d895fef354
* claim: #6646 * Control channel: document.revision, a design revision and a document id (#6646) A program that follows the open design asks document.revision and exports only when the answer moves: document_id names the open design (kept through edits, saves and renames, another for each design started or opened, never shared between two tabs or two runs) and revision moves whenever the design, what is hidden or an uncaptured component position changes. It stays put on reads, selections and view changes, unlike the session's view revision. The revision is read lazily: the session remembers the design it last reported (held weakly, so Arc::make_mut can never change it in place and its address can't be reused) and takes a new number from one counter for the whole run when the design is another one. The control method answers at once, also while a slow command computes; engine.execute reaches the same command for scripts and MCP. * document.revision: hash the run's id prefix with the process's random keys A clock set before 1970 gave every run the prefix 0, so a restarted app could answer a new design with the id and revision of the old one. The docs no longer promise an answer at once: a screenshot waiting for an opened design to be meshed still holds the requests behind it. * document.revision: its label in the complete catalogs (ja, zh) * claim: #6985 * Control channel: control.subscribe and design.changed events (#6985) A connection that sends control.subscribe gets the active design's id and revision in the reply (as document.revision answers), then a {"event":"design.changed","params":{document_id, revision}} line whenever either changes, so a live link need not poll. The window publishes the design at the end of each frame's logic and drawing while a connection is subscribed (one atomic load otherwise). Each subscribed connection waits on that from a thread of its own and writes the latest after a 100 ms gap, so a burst of changes is one line. Replies and events share one lock per connection, each written whole (#6390). * control.subscribe: the reply before any event, a second one refused The events thread started before the subscribe reply was written, so a change right after the window's answer could reach the client before the reply that named the older revision. The subscription now starts holding the connection's line lock and writes the reply under it. A second control.subscribe on a subscribed connection is refused on the connection itself: its answer could arrive behind a newer event. When no thread or socket is left for the events, the reply says it did not subscribe instead of ok. * control.subscribe: a second one does not lose a finished late reply The already-subscribed answer came before the busy check, so a request that timed out and had finished since lost its reply: control.pending then said the app ended it without one. It now comes after the busy check and drops a finished late reply as every other request does. * control_server: declare the subscribe guard at the top of the loop Clear of the lines #6643 changes (its token check moves to where the declaration was). * control_server: the subscription's items beside serve Away from the lines next to send, where #6643 adds token_of. * control test: New on a blank design reuses its tab, so redo the box first --------- Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>