From 92ae81424bb7a0d6f3f9c3c2a31ea4454b33daf2 Mon Sep 17 00:00:00 2001 From: Anton Date: Sat, 13 Jun 2026 18:17:10 +0200 Subject: [PATCH] docs(ipc): drop external-product reference from handle-push notes Reword the IPC handle-namespace doc note and the matching ipc.c comment to describe the server-initiated push behavior directly, without naming another product. --- docs/docs/namespaces/ipc.md | 2 +- src/core/ipc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/namespaces/ipc.md b/docs/docs/namespaces/ipc.md index acb58978..4f411c21 100644 --- a/docs/docs/namespaces/ipc.md +++ b/docs/docs/namespaces/ipc.md @@ -3,7 +3,7 @@ Connect to a Rayforce server (`./rayforce -p `) and exchange messages over TCP. The wire format is the same compact binary serialisation used for `ser`/`de`, with automatic delta+RLE compression for payloads larger than 2,000 bytes. All five connection builtins live here; the server-side connection hooks (`.ipc.on.open` / `.on.close` / `.on.sync` / `.on.async` / `.on.auth`) live on the [IPC Connection Hooks](../storage/ipc-hooks.md) page — they are user-settable lambda slots, not registered builtins, so they don't appear in the reference table below. !!! note "One handle namespace" - A handle is a handle, whichever side of the wire you are on: the `i64` returned by `.ipc.open` and the `h` a server-side hook receives (or reads via `.ipc.handle`) name connections in the same namespace, and `.ipc.send`, `.ipc.post`, and `.ipc.close` accept either. A server can therefore push messages back through the handle its hooks were given — from inside the hook or any time later — kdb-style. Handles are only meaningful inside the process that owns the connection; they are not stable identifiers across processes or reconnects. + A handle is a handle, whichever side of the wire you are on: the `i64` returned by `.ipc.open` and the `h` a server-side hook receives (or reads via `.ipc.handle`) name connections in the same namespace, and `.ipc.send`, `.ipc.post`, and `.ipc.close` accept either. A server can therefore push messages back through the handle its hooks were given — from inside the hook or any time later. Handles are only meaningful inside the process that owns the connection; they are not stable identifiers across processes or reconnects. !!! note "Restricted under `-U`" `.ipc.open`, `.ipc.close`, `.ipc.send`, and `.ipc.post` are `RAY_FN_RESTRICTED` — IPC chaining is blocked on a `-U` server (a peer cannot dial outward to a third server). `.ipc.handle` is always available so hooks can read the current connection ID. diff --git a/src/core/ipc.c b/src/core/ipc.c index 0c8016d3..ec9e43b8 100644 --- a/src/core/ipc.c +++ b/src/core/ipc.c @@ -1277,7 +1277,7 @@ int ray_ipc_poll(ray_ipc_server_t* srv, int timeout_ms) * ray_ipc_connect). Every entry point below resolves the handle in the * "active" poll (the poll dispatching the current hook/eval, else the * runtime's main poll), so server-side code can write to the very - * handles its hooks receive — kdb-style server push. */ + * handles its hooks receive — server-initiated push. */ static int64_t recv_full(ray_sock_t fd, void* buf, size_t len) { size_t total = 0;