logos-module-client is being archived: nothing declares it as a flake input,
nothing lists it as a dependency in the workspace dep-graph, and no source or
header outside its own tree references it.
These three generated outputs were the last thing implying otherwise. Two were
prose describing it as a repo that pins the SDK independently; three were a live
`--override-input logos-module-client/logos-cpp-sdk ...` line inside a command a
reader is invited to run. Overriding an input that does not exist is only a nix
WARNING, not an error, so the command would appear to work while doing nothing
at that path.
The live specs in doctests/*.yaml are already clean — they emit no such override.
Only outputs/*.md drifted, which is expected: they are hand-pinned and CI never
diffs them against the generator, so nothing was going to catch this.
Docs only; no spec, code or lock changes.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* Marshal inter-module calls to the owner thread
Logos inter-module calls go over Qt Remote Objects, whose replicas only
work on the thread that created them (the module's main/event-loop thread).
A module that makes calls from a worker thread — e.g. an embedded HTTP
server serving /metrics — would otherwise hang on replica acquisition.
Make LogosAPIClient transparently marshal to its owner thread when called
off-thread (guarded so same-thread calls run directly with no overhead):
- LogosAPI::getClient creates the client/consumer/replicas on the owner thread
- LogosAPIClient::invokeRemoteMethod / requestObject / onEvent run there too
New header logos_thread_marshal.h (runOnOwnerThread). No new data members —
ABI-safe for statically-linked plugins.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Add regression test for worker-thread inter-module calls
A provider records the thread its method runs on; a consumer calls it from
a worker thread via LogosAPIClient::invokeRemoteMethod. The call must execute
on the owner (main/event-loop) thread, not the worker thread.
Fails without the marshaling change (the call runs on the worker thread —
0x..d80d0 vs owner 0x..c53e0, "executed on the worker thread instead of the
owner thread"); passes with it (511/511).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Address review: async marshaling, helper constraints, test ownership
- invokeRemoteMethodAsync now also marshals to the owner thread (non-blocking
QueuedConnection) — the async path acquires a replica too, so calling it from
a worker thread previously re-introduced the off-thread bug.
- runOnOwnerThread: document the return-type constraints (void or
default-constructible, non-reference) and static_assert against references.
- test: declare the provider before its LogosAPI so the ModuleProxy (which
holds a raw pointer to it) is torn down first — removes the leak and the
inaccurate comment.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* doctest: call a module from a worker thread (HTTP server)
Adds cpp-sdk-worker-thread-http.test.yaml: builds a sensor_module callee and
an http_module caller that embeds a libmicrohttpd server, runs them in
logoscore, starts the server, and curls it. The HTTP handler calls
sensor_module.readTemperature() from the server's worker thread — which only
works because the SDK marshals the cross-module call onto the module's owner
thread. The module stays pure C++.
Wired into doctests/run.sh and the doctests CI workflow. Validated locally
(23/23 steps pass): `curl` returns `temperature 42`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
