fix: entry? symbol check, close all ports, timed receive
ober
d0d6c94cd1b86b25dcf6117e2c8fa26f2ae700d5
--- a/signal/log_crypto.ss +++ b/signal/log_crypto.ss @@ -50,7 +50,7 @@ loaded?)])) (def (entry? name) - (and (ensure-native-loaded!) #t)) + (and (ensure-native-loaded!) (foreign-entry? name))) (def (log-crypto-available?) (ensure-native-loaded!)) --- a/signal/rpc-actor.ss +++ b/signal/rpc-actor.ss @@ -135,6 +135,13 @@ [else (rpc-response-result-or-raise msg)])))) + ;; (std csp) exposes only chan-get! (blocking, no timeout) and chan-try-get + ;; (non-blocking); it has no timed blocking receive (no chan-select!/timeout + ;; variant). Without a native timed receive we cannot suspend until a value + ;; arrives or a deadline fires in a single call, so we fall back to polling + ;; chan-try-get. The short sleep bounds CPU use while keeping latency far + ;; below the RPC timeout granularity. Replace this with a real timed receive + ;; if (std csp) ever grows one. (def (chan-get-with-timeout! ch timeout-ms) (if (not timeout-ms) (chan-get! ch) --- a/signal/rpc.ss +++ b/signal/rpc.ss @@ -63,6 +63,14 @@ (let ([proc (signal-cli-proc sc)]) (close-port (process-port-rec-stdin-port proc)) (process-kill (process-port-pid proc) 15) + ;; Close the child's stdout and stderr ports too. Closing stderr + ;; unblocks the stderr drain thread spawned in spawn-signal-cli: its + ;; read hits EOF/closed-port and its guard lets it exit, so the thread + ;; is abandoned safely rather than leaked along with the ports. + (guard (_ [(condition? _) (void)]) + (close-port (process-port-rec-stdout-port proc))) + (guard (_ [(condition? _) (void)]) + (close-port (process-port-rec-stderr-port proc))) (void))) ;; --- Wire IO ---