并行同步/异步调用疑问：阻塞接收是否替代.z.ps/.z.pg？

Let’s break down your questions and observations step by step, with practical context for how q handles inter-process communication:

1. Can blocking receive constructs replace .z.ps/.z.pg calls? #

Short answer: No—they serve distinct purposes, even if they can overlap in some workflows.

• .z.ps (process start) and .z.pg (process gone) are callback hooks that trigger automatically when a remote process connects or disconnects. They’re designed for event-driven lifecycle management—think logging new connections, cleaning up resources when a process drops, or initializing state for a new peer.
• Blocking receives like h[] or h"" are for explicitly waiting on a response after sending a message to a remote process. They’re about synchronizing message flow, not reacting to changes in process state.

You could hack together logic with blocking receives to mimic .z.ps/.z.pg behavior (e.g., polling h repeatedly to check if it’s alive), but that’s inefficient and not what either feature was built for. Stick to the callbacks for process lifecycle events, and blocking receives for message synchronization.

2. Is there a delayed asynchronous mechanism similar to delayed sync (for mserve.q)? #

Great question! The delayed sync pattern in mserve.q (using value with a timeout to defer execution) doesn’t have a native "delayed async" counterpart, but you can build equivalent behavior using q’s primitives:

• Combine neg[h] (async message send) with a timer (via .z.ts or set) to schedule the async call for later. Here’s a quick example:

  // Schedule an async message to handle h in 5 seconds
  set 5000 (neg[h];({neg[.z.w] x};42))
  

• If you need to track or cancel delayed calls, wrap the logic in a helper function that manages timers and cleanup. This is a custom implementation, though—there’s no built-in keyword for delayed async like there is for delayed sync.

3. Explaining your communication test cases #

Let’s unpack why your examples behave the way they do, since this gets to the heart of how q routes messages between processes:

Case 1: Working async + blocking receive #

neg[h]({neg[.z.w] x};42); h[]  // Returns 42

Here’s the play-by-play:

1. You send an async message to h: the remote process runs the lambda {neg[.z.w] x}, which sends the value 42 back to your local process (.z.w refers to the handle of the process that sent the original message—your local one).
2. h[] blocks your local process until it receives a message from h—which is exactly the 42 sent by the remote lambda. This works because the response is routed back to your local process via the same handle h you used to send the initial message.

Case 2: Adding neg[h][] still works #

neg[h]({neg[.z.w] x};42); neg[h][]; h[]  // Still returns 42

neg[h][] sends an async "no-op" message to h—it just adds an extra task to the remote’s queue, but doesn’t interfere with the earlier lambda call. The remote still sends 42 back via h, and h[] picks it up as expected. The no-op is irrelevant here because it doesn’t affect the message routing.

Case 3: Using h"" causes an error/hang #

neg[h]({neg[.z.w] x};42); neg[h][]; h""; h[]  // Errors with 'type and hangs

h"" is a blocking call that waits for the remote process to acknowledge it has processed all messages sent to h. The problem here is a routing mismatch:

• The lambda sends its response back to your local process via .z.w (which maps to h from the remote’s perspective), but h"" only tracks messages sent to h—it doesn’t care about responses coming back.
• When you call h[] after h"", it’s waiting for a new message from h—but the remote already sent the 42 response before h"" completed. Your local process’s queue for h is empty, so h[] hangs. The 'type error stems from this misalignment between what you’re waiting for and what the remote sent.

Your observation that h[] order changes behavior is spot-on: blocking receives are tied to specific handles, and the order you call them dictates which incoming messages your process listens for. Mixing up message routing (like using .z.w in the lambda vs. expecting a response on h) creates these tricky mismatches.

内容的提问来源于stack exchange，提问作者egor7