宏中的 RemoteChannel 正在停止答案

【问题标题】：RemoteChannel in a Macro is Stalling宏中的 RemoteChannel 正在停止
【发布时间】：2017-02-09 16:50:14
【问题描述】：

我正在尝试找出如何在宏中正确使用 RemoteChannel。在函数或 REPL 中，以下代码有效：

addprocs(3)
r = RemoteChannel(3)
@spawnat(3,put!(r,10))
fetch(r) # Gives 10

但是，如果我将相同的内容放入宏中：

macro rrtest(src,val)
  quote
    r = RemoteChannel($(esc(src)))
    @spawnat($(esc(src)), put!(r, $(esc(val))))
    println(fetch(r))
  end
end

然后用相同的参数调用它

@rrtest(3,10)

然后 REPL 就会停止。像这样使用 RemoteChannels 有什么问题吗？

【问题讨论】：

标签： parallel-processing metaprogramming julia

【解决方案1】：

macro rrtest(src,val)
     quote
       r = RemoteChannel($(esc(src))) #Using a `Future` here maybe be better
       remotecall_wait(r_i->put!(r_i, $(esc(val))), $(esc(src)), r)
       wait(r);
       println(fetch(r))
     end
   end

wait(r) 应该不是必需的——fetch 在用于Future 或RemoteChannel 时应该调用wait。但有时确实如此。

将@spawnat 更改为remotecall 意味着您可以传入r，没有它，它会得到。我认为带有闭包的宏卫生嵌套是如何用宏创建自己的。 (@spawnat) 在另一个宏中创建闭包。推理是尴尬的。总的来说，我发现 @spawnat 比 remote_call 更难推理。

之所以需要remotecall_wait，是因为否则，没有garentee何时其内容将运行。这意味着r 发生的事情本身还不清楚。我觉得它应该是安全的，但似乎并不安全。我认为是因为等待r，而不是等待设置r 的remotecall 永远不会允许remotecall 运行。

结论：

更喜欢remotecall 而不是@spawnat，尤其是在宏中，为了更容易推理。
有时您必须先wait 处理事情，然后再进行fetch 处理。这可能是一个错误
有时等待 X，当 X 由返回未来 Y 的 remotecall（或 @spawnat）设置时，需要先等待 Y。也可能是一个错误

【讨论】：