IPC call in KDB

Viewed 125

I am trying to understand the IPC call in kdb. Does IPC opens multiple channel for communication between client and server one for client and other for server?

h:hopen `::port_number

A sync call to server over IPC communication channel should not it be blocked till response is received?

h"1+1"

But when I trying to make a sync call from server (in .z.pg) in same request, server request is getting filled first.

Server Side -
.z.pg:{.z.w"func[]";show "server >> ",string .z.p;"hello"}

Client side - 
.z.pg:{show "client .z.pg >",string .z.p };
func:{show "client Function >>",string .z.p};

enter image description here How this IPC commnunication flow is working as kdb is single threaded? Or there is something internally which uses multiple threads for it. e.g. one thread is waiting for response while other is free to server request on same communication channel.

1 Answers

I'm actually surprised that this doesn't deadlock but I suspect kdb recognises that this is a two-way call along the same connection and is able to allow it. I can't find any documentation or comments in the release notes to support it though.

You can even have a third process involved and not have it deadlock so long as all the sync calls are along the two-way connections. e.g. client sync calls to server1, server1 sync responds back to client but within that callback the client sync calls to server2 and server2 sync responds to the client.

/server 1
q)\p 5555
q).z.pg:{0N!`srv1;.z.w"func1[]";value x}

/server 2
q)\p 5556
q).z.pg:{0N!`srv2;.z.w"func2[]";value x}

/client
q)h1:hopen`::5555
q)h2:hopen`::5556
q)func1:{h2"1+1";0N!`f1}
q)func2:{0N!`f2}
q)
q)h1"1+1"
`f2
`f1
2

If the strict two-way calls is broken by server2 calling out to server1 (instead of requesting from client) then you get a deadlock

/on server 2
q)h:hopen`::5555
q).z.pg:{0N!`srv2;h"1+1";value x}

/on client
q)h1"1+1"

It should go without saying that these sync callbacks should be avoided

Related