how does "block ipc" work

https://learninghub.kx.com/forums/topic/how-does-block-ipc-work

Hello Everyone,

I would like to trouble you to explain how does “blocking” a handle work regards to https://code.kx.com/q/basics/ipc/#handle-messages section “block, queue, flush”.

 

I put the following code into a q file for env set-up and load the file with each q process:

.lg.t_ipc_rcrds: fliptypetimeportcontent!4#();
.z.pg:{ insert[.lg.t_ipc_rcrds; ( sync;.z.T;.z.w;x)]; value x};
.z.ps:{ insert[.lg.t_ipc_rcrds; (async;.z.T;.z.w;x)]; value x};

 

then I did a test ,pls see attached pics as the whole process. What i expected to observe is call

“7+7” “8+8” are queued in .lg.r , and call “9+9” releases the blocking, and probably all 3 calls are evaluated and logged by .z.ps on port 5001 side.

 

but here are some questions i have :

  1. refer to pic_1: seems .z.ps does not work on call “4+4” and “6+6”, why?

  2. at the end of pic_1, it shows ONLY “7+7” was queued in .lg.r, and why the following 2 calls are missed?

 

At the same time, since handle is blocked, there is no way to see the result of .z.W from port 5000.

pic_2 & 3 shows i try to re-do the test but did not work.

 

I kindly ask anyone can give a simple example to show the idea of “Blocking & Queue” and answer questions above. Many thanks !

best,

leguan

 

 

I would suggest running your examples above in the latest version of v4.0

Your version is 4yrs old - there will have been many improvements & fixes in that period

I believe that blocking/sync msg processing issue was fixed in v3.6 2021.03.04

When you invoke a handle to wait for an async message it bypasses .z.ps.

However I’m confused what happens with the 7+7 and 8+8 messages. Normally these go through .z.pg and this works even if the server is blocking waiting for an async message. So the observation should be that when sending a sync 7+7 while the server is blocking, you should still get back the result of 14 immediately.

However there are instances where combining sync and async messages in a single query cycle, with two processes sending messages to each other before returning, can lead to the messages being confused and a query returning the wrong reply.

hi jFealy, with freshly downloaded v4.0, it works now, thanks !