并行执行:阻塞接收,延迟同步
Parallel execution: blocking receive, deferred synchronous
我已经询问 关于并行同步和异步调用时发生的错误。并回答了一个更大的问题:
- 阻塞接收构造是否替换.z.ps/.z.pg调用?
- 如果存在 deferred synchronous(在
mserve.q
中使用),是否存在类似 deferred asynchronous 的东西?
我的观察基于上一个问题。该问题的案例 3 可以:
q)neg[h]({neg[.z.w] x};42); h[]
42
但是如果我们想确保我们的消息已经发送怎么办:
q)neg[h]({neg[.z.w] x};42); neg[h][]; h[]
42
看起来还可以吧?如果我们在 documentation 上更进一步,我们会发现我们有另一种类型的保险:h""
- 在远程处理的消息,在这种情况下我们有一个错误:
q)neg[h]({neg[.z.w] x};42); neg[h][]; h""; h[]
'type
<hangs>
所以命题如下 - h[]
(以适当的顺序发送)以某种方式改变了发送者的行为,并且可能是接收者进程为这种通信做好准备。
为了回答您的第一个问题,我认为“替换”不是正确的术语,而是传入的消息是预期的,因为它是由本地进程启动的,因此它不会路由到 .z.ps处理程序,与进程未预期的消息不同,其中 .z.ps 可用于确保消息不是不友好的或任何情况。
当您发出阻塞接收时,O_NONBLOCK 标志被清除并且 recvfrom() 阻塞直到消息到达并且 O_NONBLOCK 标志被替换
read(0, "h[]\n", 4080) = 4
fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(4, F_SETFL, O_RDONLY) = 0
recvfrom(4,
"[=10=][=10=][=10=][=10=][=10=][=10=]", 8, 0, NULL, NULL) = 8
recvfrom(4, "\n[=10=][=10=][=10=][=10=]unblock", 13, 0, NULL, NULL) = 13
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
关于你的第二个问题,我相信延迟同步是在 kdb+ v2.3 中引入的,用于客户端进程在等待响应时不应阻塞远程进程的场景。延迟同步允许服务器处理其他客户端请求,而您的客户端进程会阻塞,直到收到请求的信息。当客户端在收到响应之前无法执行任何其他操作时,这很好。
在某些情况下,两个进程都不应该等待另一个进程 - 您指的是这个吗?如果是这样,那么用例可能类似于分层网关系统,其中一个或多个网关 send/receive 消息 to/from 彼此,但 none 阻止或等待。这是通过异步回调完成的。在具有多个进程的复杂系统中,每个请求在飞行过程中都需要标记一个 ID,以便对其进行跟踪。同样,您需要跟踪哪个请求来自哪个连接,以便 return 结果发送到正确的客户端。
这是一个更简单的例子
////////////// PROC A //////////////
q)\p
1234i
q)remoteFunc:{system"sleep 4";neg[.z.w](`clientCallback;x+y)}
////////////// PROC B //////////////
q)h:hopen 1234
q)clientCallback:{0N!x;}; .z.ts:{-1"Processing continues..";}
q)
q)neg[h](`remoteFunc;45;55);system"t 1000"
q)Processing continues..
Processing continues..
Processing continues..
Processing continues..
Processing continues..
100
// process A sent back it's result when it was ready
关于你的最后一个问题
neg[h][]
刷新异步消息至少到 tcp/ip。这并不意味着遥控器已收到它们。
Chaser h""
刷新 h 上的所有传出消息,发送它自己的请求并处理 h 上的所有其他消息,直到它收到响应。
跟踪异步消息是一种确保它们在移动到下一条异步消息之前已在远程处理的方法。在您的示例中,挂起调用之后的跟踪是无效的,首先它会出错,其次,这不是一项需要保证在开始之前已完全处理先前的异步消息的任务。
贾森
我已经询问
- 阻塞接收构造是否替换.z.ps/.z.pg调用?
- 如果存在 deferred synchronous(在
mserve.q
中使用),是否存在类似 deferred asynchronous 的东西?
我的观察基于上一个问题。该问题的案例 3 可以:
q)neg[h]({neg[.z.w] x};42); h[]
42
但是如果我们想确保我们的消息已经发送怎么办:
q)neg[h]({neg[.z.w] x};42); neg[h][]; h[]
42
看起来还可以吧?如果我们在 documentation 上更进一步,我们会发现我们有另一种类型的保险:h""
- 在远程处理的消息,在这种情况下我们有一个错误:
q)neg[h]({neg[.z.w] x};42); neg[h][]; h""; h[]
'type
<hangs>
所以命题如下 - h[]
(以适当的顺序发送)以某种方式改变了发送者的行为,并且可能是接收者进程为这种通信做好准备。
为了回答您的第一个问题,我认为“替换”不是正确的术语,而是传入的消息是预期的,因为它是由本地进程启动的,因此它不会路由到 .z.ps处理程序,与进程未预期的消息不同,其中 .z.ps 可用于确保消息不是不友好的或任何情况。
当您发出阻塞接收时,O_NONBLOCK 标志被清除并且 recvfrom() 阻塞直到消息到达并且 O_NONBLOCK 标志被替换
read(0, "h[]\n", 4080) = 4
fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(4, F_SETFL, O_RDONLY) = 0
recvfrom(4,
"[=10=][=10=][=10=][=10=][=10=][=10=]", 8, 0, NULL, NULL) = 8
recvfrom(4, "\n[=10=][=10=][=10=][=10=]unblock", 13, 0, NULL, NULL) = 13
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
关于你的第二个问题,我相信延迟同步是在 kdb+ v2.3 中引入的,用于客户端进程在等待响应时不应阻塞远程进程的场景。延迟同步允许服务器处理其他客户端请求,而您的客户端进程会阻塞,直到收到请求的信息。当客户端在收到响应之前无法执行任何其他操作时,这很好。
在某些情况下,两个进程都不应该等待另一个进程 - 您指的是这个吗?如果是这样,那么用例可能类似于分层网关系统,其中一个或多个网关 send/receive 消息 to/from 彼此,但 none 阻止或等待。这是通过异步回调完成的。在具有多个进程的复杂系统中,每个请求在飞行过程中都需要标记一个 ID,以便对其进行跟踪。同样,您需要跟踪哪个请求来自哪个连接,以便 return 结果发送到正确的客户端。
这是一个更简单的例子
////////////// PROC A //////////////
q)\p
1234i
q)remoteFunc:{system"sleep 4";neg[.z.w](`clientCallback;x+y)}
////////////// PROC B //////////////
q)h:hopen 1234
q)clientCallback:{0N!x;}; .z.ts:{-1"Processing continues..";}
q)
q)neg[h](`remoteFunc;45;55);system"t 1000"
q)Processing continues..
Processing continues..
Processing continues..
Processing continues..
Processing continues..
100
// process A sent back it's result when it was ready
关于你的最后一个问题
neg[h][]
刷新异步消息至少到 tcp/ip。这并不意味着遥控器已收到它们。 Chaserh""
刷新 h 上的所有传出消息,发送它自己的请求并处理 h 上的所有其他消息,直到它收到响应。跟踪异步消息是一种确保它们在移动到下一条异步消息之前已在远程处理的方法。在您的示例中,挂起调用之后的跟踪是无效的,首先它会出错,其次,这不是一项需要保证在开始之前已完全处理先前的异步消息的任务。
贾森