在并行执行时-哪一侧报告错误? [英] On parallel execution - which side reports about an error?

查看:46
本文介绍了在并行执行时-哪一侧报告错误?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当使用不同的方法(同步/异步)回调呼叫者进程时,我在不同的地方都遇到错误:

When using different methods (sync/async) to callback a caller process I'm getting an error on different sides:

$ q -p 1234  │$ q
             │q)h:hopen`::1234;
             │q)neg[h]({.z.w x};42)
q)'type      │
             │q)neg[h]({neg[.z.w] x};42)
             │q)'type
             │
             │q)neg[h]({neg[.z.w] x};42); h[]
             │42

请您解释一下第一种和第二种情况的这种行为吗?为什么在第二个进程中使用同步回调命令.z.w x引发异常,而在调用方上使用neg[.z.w]回调引发异常?

Could you explain this behavior for 1st and 2nd cases please? Why does an exception raize on the 2nd process with the sync callback command .z.w x, and on the caller with the neg[.z.w] callback?

对于第3种情况:这是类似于模式(或IPC中的常见用例)的模式,用于跟踪带有空args h[]/h(::)的'sync'句柄的异步调用,以返回结果,使之成为<是em> ad-hock处理程序吗?

And for the 3rd case: is this something like a pattern (or common use case in IPC) to chase async calls with 'sync' handles with empty args h[]/h(::) to get the results back making such ad-hock handlers for them?

更新: 阻止接收构造会取代.z.ps/.z.pg调用吗?

Upd: Does blocking receive construct replaces .z.ps/.z.pg calls?

更新2: 如果存在延迟同步-是否有类似延迟异步的东西?

Upd2: If there exists deferred synchronous - is there something like deferred asynchronous?

此处中询问已更新 Upd2 .

推荐答案

以下内容应有助于澄清正在发生的事情

The below should help clarify on what's happening

情况1: 这使遥控器看起来像是失败了,但事实并非如此.正在远程使用'.z.w 42'对其进行评估,然后将同步消息发送回本地进程,并由.z.pg对其进行评估(其默认定义为value). 值42"会导致类型错误,该错误会返回到遥控器.

case 1: This gives the appearance of failing on the remote but it's not. It's being evaluated on the remote to '.z.w 42' which sends a sync message back to the local process, where it's evaluated by .z.pg (whose default definition is value). 'value 42' results in a type error which is returned to the remote.

q)h:hopen 1234
q).z.pg:{value x};system"e 1"
q)neg[h]({.z.w x};42)
q)'type
  [0]  .z.pg:{value x}
              ^
q))

情况2: 再次评估值42"(这次是.z.ps-其默认定义也是value),由于类型错误而失败,但是由于它是异步的,因此不会返回发送过程

case 2: again the evaluation of 'value 42' (this time by .z.ps - whose default definition is also value) fails with a type error but as it's async it's not returned to the sending process

q).z.ps:{value x}
q)
q)neg[h]({neg[.z.w] x};42)
q)'type
  [0]  .z.ps:{value x}
              ^
q))

情况3: 这是称为延迟同步"的IPC通信方法.发送异步消息后,我们使用称为 blocking receive

case 3: This is a method of IPC communication known as deferred synchronous. We block/listen/hang on the connection after sending the async message, awaiting a response, using a construct known as a blocking receive

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

在某些情况下,可能不必挂起连接,即,如果回调调用了像这样的另一个函数

In some cases it may not be necessary to hang on the connection i.e. if the callback invokes another function like so

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

q)add:(0N!10+);neg[h]({neg[.z.w](`add;x)};42);
q)52

此处的mserve.q中使用了延迟的同步消息传递- https: //github.com/KxSystems/kdb/blob/master/e/mserve.q

Deferred synchronous messaging is used in mserve.q here - https://github.com/KxSystems/kdb/blob/master/e/mserve.q

这篇关于在并行执行时-哪一侧报告错误?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆