并行执行:阻止接收，延迟同步 [英] Parallel execution: blocking receive, deferred synchronous

问题描述

我已经问过问题有关并行同步和异步调用时发生的错误.答案揭示了更大的问题:

I've asked a question about errors that happened while parallel sync and async calls. And answer shed light on an even bigger questions:

• 阻止接收构造会替换.z.ps/.z.pg调用吗?
• 如果存在延迟同步(用于mserve.q)，是否存在诸如延迟异步之类的东西?

• Does blocking receive construct replaces .z.ps/.z.pg calls?
• If there exists deferred synchronous (used in mserve.q), are there something like deferred asynchronous exists?

我对上一个问题的观察.该问题的情况3可以:

My observations based on the previous question. Case 3 from that question is ok:

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

但是，如果我们要确保已发送邮件，该怎么办?

But what if we want to ensure that our message have been sent:

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

似乎还可以吧?如果我们进一步研究文档，我们会发现还有另一种类型的保险:h""-远程处理消息，在这种情况下，我们会出现错误:

Seems ok, right? If we go further on the documentation we find out that there another type of insurance we have: h"" - message processed on remote, and in this case we've got an error:

q)neg[h]({neg[.z.w] x};42); neg[h][]; h""; h[]
'type
<hangs>

因此，命题如下-h[](以适当的顺序发送)以某种方式改变了发送者的行为，并且可能是接收者为进行此类通信准备的过程.

So the proposition is the following - h[] (sent in the appropriate sequence) somehow changes the behaviour of a sender and may be a receiver process to prepare them for such communication.

推荐答案

要回答您的第一个问题，我认为不可以替换".是正确的术语，而是预期传入消息是由本地进程启动的，因此它不会路由到.z.ps处理程序，这与进程不希望使用的消息不同，在该消息中，.z.ps可用于确保消息不友好，无论情况如何.

To answer your first question, I don't think "replace" is correct term, rather the incoming message is expected as it was initiated by the local process, therefore it's not routed towards the .z.ps handler, unlike messages which the process wasn't expecting, where .z.ps can be used to ensure the message isn't unfriendly or whatever the case may be.

发出阻止接收时，O_NONBLOCK标志被清除，recvfrom()阻止，直到消息到达& O_NONBLOCK标志被替换

When you issue a blocking receive, the O_NONBLOCK flag is cleared and recvfrom() blocks until a message arrives & the O_NONBLOCK flag is replaced

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,


"\1\0\0\0\25\0\0\0", 8, 0, NULL, NULL) = 8
recvfrom(4, "\n\0\7\0\0\0unblock", 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中引入了延迟同步，用于客户端进程在等待响应时不应阻止远程进程的情况.延迟同步允许服务器处理其他客户端请求，而客户端进程将阻塞直到收到请求的信息.当客户端在收到响应之前不能做其他任何事情时，这很好.

On your second question, I believe deferred synchronous was introduced in kdb+ v2.3 for the scenario where a client process shouldn't block the remote process while it waits for it's response. Deferred synchronous allows the server to process other client requests, while your client process blocks until the requested info is received. This is fine when the client can't do anything else until it receives the response.

在某些情况下，两个进程都不应该等待另一个进程-这是您所指的吗?如果是这样，则用例可能类似于分层网关系统，在该系统中，一个或多个网关相互之间发送/接收消息，但没有一个阻塞或等待.这是通过异步回调完成的.在具有多个进程的复杂系统中，每个请求在运行过程中都需要用ID进行标记，以便对其进行跟踪.同样，您将需要跟踪哪个请求来自哪个连接，以便将结果返回给正确的客户端.

There are cases where neither process should wait for the other - is this what you're referring to? If so then a use case might be something like a tiered gateway system, where one or more gateways send/receive messages to/from each other, but none block or wait. This is done via async callbacks. In a complex system with multiple processes, each request needs to be tagged with an ID while they are inflight so as to track them. Likewise, you would need to track which request came from which connection so as to return results to the correct client.

这是一个更简单的示例

////////////// 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

关于最后一个问题

1. neg[h][]至少将异步消息刷新到tcp/ip.这并不意味着遥控器已收到它们. 追踪器h""刷新h上的所有传出消息，发送自己的请求&处理h上的所有其他消息，直到收到它的响应为止.

1. neg[h][] flushes async messages as least as far as tcp/ip. This does not mean the remote has received them. The chaser h"" flushes any outgoing messages on h, sends it's own request & processes all other messages on h, until it receives it's response.

追逐异步消息是一种确保在移至下一个异步消息之前已在远程上对其进行处理的方法.在您的示例中，追随电话和挂机电话无效，因为其中一个将导致错误&其次，这不是一项必须保证以前的异步消息在开始之前已被完全处理的任务.

Chasing async messages is a way to ensure they've been processed on the remote before moving onto the next async message. In your example, the chase followed by a hanging call isn't valid, for one it will error & secondly, it's not a task which requires a guarantee that the previous async message was fully processed before commencing.

Jason

这篇关于并行执行:阻止接收，延迟同步的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！