What does \t (neg h)"command"; h"command" return?

[michaeljames]

Happy Friday all, had a few questions about the mechanics of IPC:

1. Are IPC messages sent in a FIFO (first in, first out) queue? For example, say I am a client sending IPC messages m1, m2, m3 in that order to a server. Will the server process m1, m2, m3 in that same order?

2. Is the above true whether the messages are sync or async?

3. I'll define some variables to make discussing the following points easier:
Let x represent some command or data, which when processed by q yields output f(x).
Let t1 = time for client to send "x"
Let t2 = time for server to calculate f(x)
Let t3 = time for client to receive f(x)

If I enter into the q console,
\t h"x"
Is the result t1 + t2 + t3 ?

4. What of async calls:
\t (neg h)"x"
Is the result simply t1?

5. This is more interesting - if we send several async calls, then a sync call,
\t do[10;(neg h)"x"]; h"x"

What is this? Is it 10*(t1+t2), for the 10 async calls, plus t1+t2+t3, for the last sync call?

Kind regards,

Michael

[gyorokpeter-kx]

1. They will be in order.

2. Yes, but for sync messages the client will block until it gets the reply. It may get confused if the server also sends messages as part of processing the query, resulting in the client pairing the wrong reply to the sync message.

3. Yes

4. It's actually the time to enqueue the message in the output queue, which is usually instant unless the queue is full, in which case it may block. Adding a flush (::) blocks until the message is handed over to the TCP stack.

5. It's easier to not break it down in terms of t1/t2/t3 but think of it as being the time difference between starting the whole command and receiving the reply to the sync message. That means all the async messages and the sync message must reach the server, then the server must process them, then send back the reply to the sync message, which the client must process. Since the operations covered by t1 and t2 are not synchronized, they are not additive.