什么'；erlang进程运行'receive after'时的进程状态是什么？

我想知道该进程运行时erlang进程的状态

receive after

：

receive
  X ->
    ok
after 1000 ->
   ok
end

1、 进程状态是正在运行还是正在等待

2、 此进程是否将使用cpu schedler时间

3、 如果我有120000个这样的erlang进程，每个进程都会运行这样的代码：

receive
      X ->
        ok
    after 1000 ->
       ok
end

---

那么，这段代码会成为瓶颈吗？

这个过程只是随着接收表达式后面的内容而移动

例如，假设一个内联的请求/响应：

ask_foo(SomePID) ->
    Ref = make_ref(),
    SomePID ! {self(), Ref, why},
    receive
        {Ref, Answer} ->
            io:format("The answer: ~tp~n", [Answer])
      after
        1000 ->
            io:format("~p is too slow. Moving on...~n", [SomePID])
    end,
    io:format("I'll print this in any case, and then exit.").

receive

阻塞，直到它接收到与其receive子句之一匹配的消息，或者超时发生（以先发生的为准）。然后，它继续执行代码中的任何其他操作。通常会有一个

receive

循环，但对于应该阻塞、like或类似的内容，使用一系列内联

receive

子句并不少见

就其状态数据而言，“进程的状态”根本没有改变。它处于阻塞状态，这意味着它将被挂起，直到出现消息或超时。但是，与轮询系统不同，这不会带来开销损失，因为VM正在管理调度（进程不必唤醒自己，它可以安全地阻止

接收

）

---

您询问这是否会成为瓶颈：不，没有其他进程被阻塞，只有这一个。所有其他进程都按照自己的时间表执行，它们与此无关。因此，当在接收上阻塞时，您只会阻塞这个特定进程应该执行的其他操作。因此，这是否是一个瓶颈成为一个体系结构问题。

情况如何：12000进程同时运行

receive after

，这是一个瓶颈吗？我的意思是，

同时

@BlackMamba 12000个进程在一次接收时阻塞与100000个进程在一次接收时阻塞是一样的。这不是任何开销。如果它们都在同一时间接收到消息或超时，那么执行相关语句时会有很大的负担，但是阻塞接收本身并不是很大的开销。在计时器之后一次勾选12000个

可能会产生开销——但我认为这实际上会以一种奇怪的方式影响到您：计时器不会全部有效地结束为1000毫秒，因为一次勾选它们会导致争用。另一个问题：当进程运行时
收到一个
，它的状态是“阻塞”

，erlang调度程序如何处理该进程？@BlackMamba等待消息的进程在其邮箱中有新消息之前不会被调度。这是一个反应性活动，而不是轮询活动——这就是为什么这不会给正在运行的节点增加开销。虽然有一些细节是如何工作的，但是深入研究它确实需要一个新的问题。基本情况是，在接收到消息之前，

receive

上的任何进程阻塞都不会被调度。